- Introduction
- B2B E-Commerce Primer
- Overall Function Point Counting and Estimation Methodology
- Benefits of Function Point Counting and Estimation
- Extensions to IFPUG CPM 4.1
- The Function Point Counting and Estimation Repository
- The Function Point Counting and Estimation Team-based Process
- Function Point Estimation Worksheet Example Segment
- Other Applications
- Internal Challenges at eSell
- Summary and Conclusions
- Final Questions to Ponder
This chapter is from the book
This chapter is from the book
This chapter is from the book
Extensions to IFPUG CPM 4.1
To seamlessly integrate FP into the Web development/deployment fabric, eSell has extended and adapted standard IFPUG counting practices found in the CPM 4.1. This was necessary to accommodate some of the differences that Web-enabled business application development creates over traditional mainframe or client-server software projects. Following are examples:
Web-application graphical user interfaces (GUIs) are somewhat different, affecting External Input/External Output/External Query (EI/EO/EQ) measurement. Logical business transactions often require multiple physical Web screens with embedded navigation. The challenge is to identify the elementary process as distinct from the highly user-friendly GUI-oriented implementation.
Web GUIs are built dynamically. Their layout, data fields, and even cosmetics are determined at run time as a function of system and end-user factors. Thus the number of data element types (DETs) and file type references (FTRs) for a particular EI/EO/EQ changes as the online transaction progresses or between online transactions. This had to be accommodated.
Web-based transactions typically require more master detail or drill-down displays; this is especially challenging when one is defining differences between physical and logical functionality. Web GUIs use drop-down boxes or combo boxes, often populated by complex dynamic queries (EQ). The ratio of EQ to EI/EO is typically higher than in a traditional mainframe or client/server application.
Web-based applications are typically embedded in a multi-tier architecture, often requiring as many as four or five tiers. These tiers could be composed of actual end-users or other back-end systems. The issue of exactly where the application boundary lies in such a complex topology is challenging.
E-commerce systems integrate with ERP systems. These multi-million-dollar systems are highly complex, configurable, and also programmable. During the Web deployment, the ERP systems must be customized and reconfigured. Thus, identification of the FP Boundary is a non-trivial task. Data stores (ILF) may exist not only in the Web application but also in the ERP system. ERP programmable components (business objects, remote function calls, and the like) are counted as data stores (ILF/EIF), since their primary intent is to manage ERP business data.
Web-based applications are highly interactive, requiring real-time access to multiple disparate back-end systems. This may include direct access to back-end databases or indirect access to these data stores by way of business logic in intervening application servers. Complexity is added to determining exactly what are the ILF/EIF files and what are simply EI/EO system-to-system pairs.
In B2B (ERP-integrated e-commerce, in particular), Web-based applications are developed by project teams with disparate though complementary skill sets, such as
- Project management
- Java development
- ERP language development
- ERP system functional expertise
- System administration
- Network administration
- Graphics art, page layout, human factors expertise
This adds challenges to the process of gathering productivity data (for example, function points per staff-month) for the team and for the individual roles on the team.
Over the two years eSell has been doing project sizing and estimation, they have accumulated a productivity and size historical database. This productivity database (PDB) plays a crucial role in predicting future results based on past projects. With this data, eSell has performed almost 100 project-sizing and effort/cost estimations and scores of full-application-sizing FP counts.
This work has yielded some startling results:
Due to eSell's rapid application development (RAD)2 project approach and recurrent FP process, the RAD-oriented development environment, the reliance on object-oriented design and tools, and other critical factors, the product development and deployment productivities showed marked improvement over industry-standard norms. For example, the conventional wisdom indicates that a respectable average team productivity is approximately 8 to 10 FP per staff-month. However, in our PDB, we have found a range of 14 to 74 FP per staff-month with an average of about 25 FP/SM. This is an overall improvement factor of over 700 percent peak-to-peak and an improvement of 250 percent on average. Is this because our teams are smarter? No. It is because rapid application development (RAD) and function point analysis (FPA) prevent the teams from spending inordinate amounts of precious and costly project time building functionality that will ultimately be rejected by the ultimate end-user—and thus not productive.
eSell's measurements have shown a high degree of accuracy in the estimations, sometimes achieving ±2 percent error rates in resultant staff-day figures. Is this because we have a better measurement staff? No. It is because we estimate at a very fine grain (the ability-to) and measure and correct at that fine grain. Accuracy must improve.