This should be one of the last things that you read, and one of the first things I that I have written. You should be estimating based on the more physical items, like Adding an Output Screen. I should treat this as a template for how to add various objects. Unfortunately, there may be a time when an estimator is trying to estimate an application where none of the elementary processes seem to fit the ones that have been presented in this methodology. This process can be evaluated using this approach. Alternately, this can act as a template to build some other estimating templates that will be more useful to estimate applications similar to the one with the unrecognizable processes.
An elementary process is the smallest business process that an end user would be interested in. It frequently corresponds to a user story. For example, “As a author, I can publish a post to the site.” For our purposes, it is an automated operation that has the following characteristics:
- It is performed by a single person or process. The process might be another application. In the example above, the author is the single person. Now, you might wonder what happens if the post takes multiple sessions of editing? You might have to adjust the user stories to reflect that posts can be added or changed, and that they may be saved as drafts or published. Thus, we might end up with a half dozen user stories and elementary processes. In an elementary process, the user is not always human. Some people write their blog posts using Evernote. In synchronizing between WordPress and Evernote, Evernote is a user.
- It is completed at one time. This is why the posting a blog story is not an elementary process. One of my professors used to say there was no such thing as writing, only rewriting. In any case, an elementary process should be completed at one time. If you have epic stories, they must be broken up into their component elementary processes.
- It is preformed at one location. Given the laws of physics, if something is completed at one time, it is probably performed at one location. A process that began when a package was picked up at one address and ended when it was delivered at another location would have to be more than a single elementary process.
- It responds to an event. Normally, an elementary process is a response to a business event. For example, if you receive a check, you must enter it into the system as part of the deposit process. Scheduled events can fall into this category. For example, sending a statement to customers at the end of the month is an elementary process.
- It leaves the data in a consistent state. An obvious example is changing an address. If you change the city without changing the state, then the address is in an inconsistent state. Therefore changing the city is not an elementary process. Changing the address might be. Changing profile information usually is. There are other cases that must be considered. For example, is adding a dependent on an employee record an elementary process, or is it part of the elementary process of changing employee information. It is probably the latter, since having no or incorrect dependent information leaves the employee data in an inconsistent state.
Elementary processes often become function point transactions: External Inputs (EIs), External Outputs (EOs) or External Inquiries (EQs). Every transaction must cross the application boundary. If its primary intent is to put information into the application, then it is a EI. Transactions that send information beyond the application boundary are either EOs or EQs. The differences between EOs and EQs will be described below.
Elementary processes do not always become separate function point transactions. For example, suppose you had an application where one elementary process was to produce a printed report and another was to fax the same report. They would become part of the same EO or EQ. This is because they would be displaying the same DETs and accessing the same logical files to generate both versions of the report. If you were developing both elementary processes for the same release, you would probably have the same developer or developer pair working on both. It would not take much more time to deliver both, than delivering one. If neither version of the report had been developed, and only the printed version was being developed for the next release, then the size of the report should be calculated using function points. That procedure is described below. If the printed report had been developed for a previous release, the fax version should not take as long as developing it from scratch. This would be true even if we were simultaneously changing the printed version. In either case, use SNAP points to count this new version as a change to the printed version. This process is described in a separate post, Changing an Elementary Process.
Roberto Meli found that once it had been decided that an elementary process was a function point process, i.e. an EI EO or EQ, then its most likely size was 4.4 function points. It may seem that if you have no idea whether you are estimating an input or an output, then you do not know enough about the application to do any estimating at all. That is not completely true. There have been cases where the development team must build an application program interface (API). You may see methods with names like SendSomeObject. You might not be sure whether the application that you are estimating is sending the object, or whether the application your application is interfacing with is sending the object. You might be able to find out, but is that the best use of your time at the point when you are making this particular estimate.
Sizing External Inputs (EIs)
Roberto Meil has found that the most likely size of an EI is 4.2 function points. Another possible way to size an EI is by checking the user story for any keywords in the list below. When a user story contains one of these keywords, there is a good chance that it is an EI with the indicated number of function points in size. Use this as your estimate unless you have reason to believe otherwise.
Sizing Based on File Types Referenced (FTRs) and Data Element Types (DETs)
The number of function points for an EI can be derived based upon the number of File Types Referenced (FTRs) and Data Element Types (DETs). FTRs is the number of logical files that are being accessed in order to display the output. It also includes any files that are written to but not read from. Part of the estimating process is to maintain a list of these logical files.
DETs are basically the fields that are transferred across the application boundary by the elementary process. There is one extra field called the action code. Even if it is not visible, it is assumed to be there. Thus, there is always at least 1 DET on an output screen. There is also a DET if the elementary process might generate an error message. For example, if there were a selection field to return posts that met some type of criteria, like a date range and the user entered an invalid date, then an error message would be generated. This would be counted as a DET. If the screen generated error messages for invalid dates, invalid amounts and other invalid input, the error messages would still be considered a single DET. Each of the fields crossing the application boundary are possible DETs. They must be unique. In other words, if the same field is occurs twice, it is only counted once. Likewise, if a set of fields are transferred for each of 12 months, it is only counted as a single DET.
EI are between 3 and 6 function points. The matrix below shows the how the function points are assigned. Note that the diagonal from the lower left to the upper right have the same values and they correspond to an average EI. The cells on the upper left correspond to lower sized transactions, while those on the lower right correspond to higher size.
It is important for estimators not to become obsessed with exact numbers for DETs and FTRs. First, it does not matter whether your DET count is any number between 5 and 15, your estimate will come out the same. When you have a FTR of 1, any DET count less than or equal to 15 will yield the same number of function points. If you are estimating schedule and effort, you are going to look at many transactions. You will then have to estimate the values for over a dozen cost drivers. If you a a product owner, you will also have to identify the most important stories to implement in the next iteration. You will be involved in other activities such as communicating with the user community. You just do not have time to obsess over DET and FTR values. Guess a little!
Sizing External Inquiries (EQs) and External Outputs (EOs)
An output function point transaction might correspond to either an External Inquiry (EQ) or an External Output (EO). Roberto Meli has analyzed a corpus of function point counts and determined that the most likely function point size associated with an output (when it has not been determined whether it is an EQ or an EO) is 4.6 function points. This could be used as an estimate.
A different corpus of function point counts was subject to keyword analysis. The following slide shows the result for output transactions. When a user story contains one of these keywords, there is a good chance that it is an EQ or an EO that is the indicated number of function points in size. Use this as your estimate unless you have reason to believe otherwise.
The definitions of EQs and EOs can be used as a clue as to which type of output transaction this is. If the transaction reads from the logical files being maintained by the application and outputs some of their content, then the transaction is an External Inquiry (EQ), unless there is a complication. If there is a complication, like the transaction requires calculations or writes information to a logical file, then it is an External Output (EO). Roberto Meli has found that the most likely size of an EQ is 3.9 function points; for an EO it is 5.2.
The number of function points for an output can be derived based upon the number of File Types Referenced (FTRs) and Data Element Types (DETs). Counting FTRs and DETs was described in “Sizing Based on File Types Referenced (FTRs) and Data Element Types (DETs),” above. EQ transactions are between 3 and 6 function points; EOs are between 4 and 7. The matrices below show the how the function points are assigned. Note that the diagonal from the lower left to the upper right have the same values and they correspond to an average output. The cells on the upper left correspond to lower sized transactions, while those on the lower right correspond to higher size. The EO is 1 function point higher in each cell.
The same comments regarding counting FTRs and DETs apply here as were described above. It is seldom worthwhile to agonize over a DET or two. When adding an elementary process, the exact number of FTRs and DETs may not be known. When you take guesses, the errors will tend to cancel out. You will sometimes guess too high, but on another transaction you will guess too low. This is true of random errors. If you are are making systemic errors, the result will be a poor estimate. For example, if you always choose the highest value it could possibly be, then you estimate will end up too high. Make your best estimate and move on to the other tasks that must be performed.