| Author | Message | |||
     RaeAnn Burns |
I have been asked to estimate the size of a project that will utilize EAI functionality. The user of Application A and Application B wants to be able to update both applications in each direction; A updates B and B updates A. I had to draw a picture in order to understand what the user is asking for. While drawing the picture I added in the requirements (numbered) and what I believe to be the transactions to be counted. I would appreciate some input on counting an EAI application.
RaeAnn Burns | |||
| Gene Fellner |
Hi RaeAnn, If I understand your diagram correctly (and it was well drawn, good job!), neither application actually performs an update directly to the other application's file. Therefore you don't have to count it as an ILF for both systems. In fact, I don't see evidence that they even read each other's file directly, so you don't have to count it as an EIF either. They are sending transactions back and forth to each other and letting each one update its own ILF. The update is an EI to the system that receives the transaction and performs the update. It is an EQ or an EO to the system that initiates it. (Need more info to decide if it satisfies the definition of an EO, and I'm assuming--rather than concluding--that it at least satisfies the definition of an EQ.) The status messages are just like error/confirmation messages, one extra DET on the EI, not a separate elementary process. The other stuff looks like "scaffolding," technical implementation outside the end user's field of view. The "EAI Layer" does indeed operate beneath the application layer. In my 3-D Application Boundary Diagram it would be presented that way, although I don't know how to format it for a 2-D screen! Now, just one more question: Are you sure these are two separate applications? When I see so much data going back and forth across an "Application Boundary" that someone has gone to great lengths to make nearly invisible to the end user, I can't help wondering whether the end user would recognize this picture. Could they identify those EIs and EOs as something that satisfies their requirements? Application Boundaries that are too small are the leading cause of Function Point Inflation. Hope this helps, --Gene | |||
| RaeAnn Burns |
Thanks for your response Gene. In answer to your question as to whether there are two applications or may be just one. The reasons the apps have been defined as two separate apps follow: 1. different users/different points of view application A is an order entry system for phone service and application B is the telephone switch, so once an order is complete (entered into application A, then the switch is manually updated/programmed (current process) 2. different data requirements Now I have a question back to you....Is the EAI layer functionality that can be counted or would you count the ability of the two applications to update one another? I am afraid I may be overcounting. Is the EAI layer a separate application; separate from A and B? Thank you, RaeAnn RaeAnn Burns | |||
| Gene Fellner |
I would count the applications as I did in my previous posting, i.e. the messages are passing directly from one to the other. The EAI layer is infrastructural software. The way my 3-D model explains this is that horizontal boundaries are opaque from the top, meaning that the upper software doesn't see the lower and therefore assumes it is communicating directly with its peers; whereas they are transparent from the bottom, meaning that the lower software does see the upper and counts all the communication with it as functionality. You can do an FP count on infrastructural software, but it is a daunting and often thankless task. The definition of the "end user" whose perspective you seek to adopt is elusive. Although infrastructural products may have a more or less extensive interface with people, most of their functionality involves moving data to and from other software. The subject matter experts aren't much help because they are developers, not civilians. And when you get done, what are you going to do with the FP count? It's hard enough to develop FP-based productivity and quality benchmarks for end user applications. Who wants to try to compare Windows NT with Macintosh OS-X? I always advise my clients to put infrastructural software at the bottom of their priority list. When everything else in the shop is counted and you still feel like counting more Function Points, then take a crack at the message routers and firewalls. At least after getting all that experience you might be skillful enough to do a good job of it! As for your application boundary, I'm not sure what you mean by a telephone switch. Different users, different points of view and different data requirements are persuasive, but not conclusive evidence of a boundary. I ask one question several times from different perspectives: If I show this diagram to an end user who is not very computer literate, will she understand it? Will she recognize the dataflow between the two "applications"? Will she agree that those inputs and outputs were developed to satisfy her requirements? Or will her eyes glaze over as she says, "Oh, that's just technical stuff that the programmers had to do to make it work right." Good luck, Gene |
EAI Functions
