Shulou(Shulou.com)06/03 Report--

preface

The target audience for this article is those engaged in software development workload evaluation using FPA function point methodology in the software industry. Some common problems in FPA method practice are listed, including the definition of FPA method evaluation standard and the method suggestions obtained in practice, which are only for reference.

I. Help Documents

Help functions in an application usually come in three forms.

Help for the application-Help in this case applies to the entire application, usually in the form of the Help menu on the GUI system.

Help in the form of screens-Help in this case applies to specific screens in GUI or Web-based systems.

Help in the form of fields-Help in this case applies to specific fields in the application.

4. According to FPA method,"help information" counts as an internal logical file, and each "help" counts as a transaction function (provided that "help information" is maintained by this system). Complexity is usually low.

"Help" and "About" are often coded data or static pages, usually not counted.

As shown in the figure:

II. Navigation menu

Navigation menu bars are common in web framework systems, which can be configured and adjusted according to page layout needs or function layout needs. Such menus can usually be configured and adjusted at the back end, and displayed at the front end through real-time query. However, this kind of function is a kind of coded data, usually only menu number, menu name, menu link, menu serial number and other fields, there is no actual business meaning. When counting function points, no counting is performed.

As shown in the figure:

III. Diagrams

Charts can be displayed and generated in a variety of ways:

1. Real-time query report, which is a basic process from data generation to query presentation to users, usually counted as EQ or EO, without mathematical operation or derivative data generation identified as EQ, otherwise identified as EO.

2. Generate report data in advance through batch processing and land it in the database, and display the report data in the query interface. In terms of basic processes, these are two basic processes. The basic process for batch generation of report data is identified as EI, and the process for querying presentation of report data is identified as EQ or EO. At this time, should the report database table stored on the ground be counted as an internal logical file? From FPA methodology we know that all things functional (EI/EO/EQ) must reference or maintain internal logic files or external interface files. If you don't count internal logical files, can't you count things for report generation and query? In the process of report implementation, we found that the main workload is in report generation and report query development. A logical file in standard functions usually corresponds to 4 - 6 basic processes, such as adding, deleting, checking and providing interfaces. At this time, the report data is only a processed thing data, not a new logical file. Therefore, according to our experience, only counting batch report generation process EI and query report data process EQ/EO can be generated through batch processing.

3. The same report has both tables, pie charts and bar charts to display. As usual, tables show detailed data, bar charts show summary sorting, and pie charts show percentage classification. Therefore, the field attributes and business requirements displayed in each diagram are different. Each chart shall be counted individually as EQ/EO when counting function points.

IV. Printing and export

Print and export functions are divided into two cases:

1. Print and export on the basis of query list. At this point the query list has been individually counted as an EQ or EO. Printing and export are executed on this basis. The processing of query data can be reused. Thus printing and exporting can be counted as a separate thing function EQ or EO, respectively, but the degree of reuse can be identified as high.

2. Directly input query data range or data category for export. At this time, there is no query list, so the export and print functions can be counted as an independent thing function EQ or EO respectively, and the single reuse degree can be recognized as low.

V. SMS code sending

In some systems with high security requirements or system login registration process, we often encounter the process of requiring input of mobile phone number to obtain Captcha for identity authentication. Is the ability to send SMS Captcha a separate basic process countable function point? The answer is no. We found that sending SMS Captcha is not the main business purpose. It is often necessary to verify or register our identity in the process of registration, login, payment and account inquiry before we are required to obtain SMS code for verification. Without Captcha verification, our main business purpose cannot be completed. Therefore, SMS Captcha is not the main business purpose, but only a processing logic among other functions. When counting function points, the function is not counted.

VI. Approval Process

At present, the process approval function of most systems is realized through process engine configuration.

1. If the process is newly created or modified by developers through configuration + development. In this case, the user cannot maintain it. Therefore, this process itself is not ILF; what the user perceives is transaction functions such as submission, approval, and approval, which can be counted and counted according to the approval node. The reuse degree is generally high, and it can be deduplicated according to the de-duplication principle. Approval and rejection in the approval node are regarded as an approval function and are two different states or branches of approval results.

2. If the process engine is open for business users to operate, count the functions of the process engine itself. The specific process added or modified by users cannot be counted as ILF itself, and similarly, submission and approval are not counted. Just like a user adding or modifying a specific customer information in the CRM system.

VII. Migration

Migration itself is a non-functional requirement, since its workload can be quantified, so in addition to environmental preparation, its own development workload can be counted according to custom rules.

Function migration, usually processing logic, data fields, data access methods will change, can be identified as modifications to the original function.

2. Data migration: identify the number of logical files to be migrated, each logical file migration corresponds to an EI, and count the number of EI as the counting result of data migration work function points. From the actual operation process is sometimes difficult to identify whether it is a logical file, you can identify a physical table as an EI in disguise, and the reuse degree is medium or high.

The migration project assessment methodology is a recommendation only and not a standard in the FPA Standard Function Point methodology published by IFPUG.

VIII. Microservice architecture system

Microservices architecture is an approach to developing a single application as a set of small services, each running in its own process and communicating with lightweight mechanisms (usually APIs for HTTP resources). These services are built around business functionality and can be deployed independently through fully automated deployment mechanisms. Centralized management of these services is already minimal, and they can be written in different programming languages and use different data storage technologies.

When counting the function points of a microservices architecture system, the first thing we need to consider is the system boundary. The purpose of measurement is to manage services, so when dividing system boundaries, it is necessary to comply with the management requirements of the organization and the organization's definition of the system. If each IT system is defined by the organization, the standard function point method is used to count the number of systems defined by the organization. Within a system boundary, there are multiple MSUs, each MSU has an independent database, and the MSUs use interfaces to access or transmit data, and their main workload is also concentrated on the interface development and logic processing between the MSUs. Therefore, when counting the function points of a microservice system, each microservice unit can be divided into small boundaries to identify the corresponding thing function, and the data function is not identified. Because there is one and only one identical logical file within a system boundary.

The Microservices Architecture System Assessment methodology is a recommendation only and not a standard in the FPA Standard Function Point methodology published by IFPUG. (Beijing Software Cost Evaluation Technology Innovation Alliance)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.