The information collected during the analysis forms the backbone for critical decisions with regards to the complexity, resources, frameworks, time schedule, cost, etc. Over the years, there have been several techniques to simplify the project analysis phase, but most of them still remain inadequate when considering the accuracy of the outcome.
Even clearly defined projects can fall out during the later stages without an accurate analysis methodology in place. Mitigation of risk in software projects turns out to be of prime importance. Usually, it starts with delineating precise measurements concerning the scope, performance, duration, quality and other key efficiency metrics of the project.
Advanced analysis techniques like Function Point Analysis FPA bring a clear picture regarding each of these metrics, chiefly related to the project scope, staffing, cost and time, which helps in the management, control, customization of software development right from its initial planning phases. Function Point Analysis is a standardized method used commonly as an estimation technique in software engineering.
First defined by Allan J. In simple words, FPA is a technique used to measure software requirements based on the different functions that the requirement can be split into.
It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:. Example: Compute the function point, productivity, documentation, cost per function for the following data:. JavaTpoint offers too many high quality services. Mail us on [email protected] , to get more information about given services.
Please mail your requirement at [email protected] Duration: 1 week to 2 week. Software Engineering. Coding Programming Style Structured Programming. Reinforcement Learning. R Programming. React Native. Python Design Patterns. Python Pillow. Click here to download the unabridged PDF version of this document. Industry experience has shown that an emphasis on project management and control offsets much of the risk associated with software projects.
One of the major components of better management and control of both in-house development and a package implementation is measurement. Knowing the software size facilitates the creation of more accurate estimates of project resources and delivery dates and facilitates project tracking to monitor any unforeseen increases in scope. The measurement of the performance indicators enables benchmarking against other development teams and facilitates better estimating of future projects.
The benefits of using measurement to support management decision-making, can only be achieved if the information supporting these decisions is relevant, accurate and timely.
The cost of implementing the activities, procedures and standards to support the function point counting process will depend on the size and structure of the organisation and their measurement needs. A recommended approach for developing function point counts is to first functionally decompose the software into its elementary functional components base functional components. This decomposition may be illustrated graphically on a functional hierarchy.
This approach has the advantage of being able to easily convey the scope of the application to the user, not only by illustrating the number of functions delivered by each functional area, but also a comparative size of each functional area measured in function points.
If the software to be developed is planned to replace existing production applications, it is useful to asses if the business is going to be delivered more, less or the same functionality. A quantitative assessment of the difference can be measured in function points.
Note, this comparison can only be done if the existing applications have already been sized in function points.
Multiplying the size of the application to be replaced by an estimate of the dollar cost per function point to develop, enables project sponsors to develop quick estimates of replacement costs. Industry derived costs are available and provide a ballpark figure for the likely cost. Industry figures are a particularly useful reference if the re-development is for a new software or hardware platform not previously experienced by the organisation.
Package costs typically need to include the cost of re-engineering the business to adapt the current business processes to those delivered by the package.
These costs are usually not a consideration for in-house developed software. Initial project estimates often exceed the sponsor's planned delivery date and budgeted cost. A reduction in the scope of the functionality to be delivered is often needed so that it is delivered within a predetermined time or budget constraints. It enables the project manager and the user to work together to identify and flag label those functions which are: mandatory for the first release of the application; essential but not mandatory; or optional and could be held over to a subsequent release.
The scope of the different scenarios can then be quickly determined by measuring the functional size of the different scenarios. For example, the project size can be objectively measured to determine what the size and cost and duration would be if all functions are implemented, only mandatory functions are implemented, only mandatory and essential functions are implemented. This allows the user to make more informed decisions on which functions will be included in each release of the application, based on their relative priority compared to what is possible given the time, cost and resource constraints of the project.
Functionally sizing the requirements for the application quantifies the different types of functionality delivered by an application. The function point count assigns function points to each of the function types: External Inputs, Outputs, Enquiries, and Internal and External Files. The profile of functionality delivered by each of the function types in a planned application can be compared to that of the typical profile from implemented applications, to highlight areas where the specifications may be incomplete or there may be anomalies.
The following pie chart illustrates the function point count profile for a planned Accounts Receivable application compared to that from the ISBGS data. The reporting functions outputs are lower than predicted by industry comparisons. Once the scope of the project is agreed, the estimates for effort, staff resources, costs and schedules need to be developed.
If your organisation has only just begun collecting these metrics and does not have sufficient data to establish its own productivity rates, then the ISBSG industry data can be used in the interim. FSM measures the functional requirements of the software. This capability to measure early, enables accurate estimates to be made, risks to be evaluated and project scope to be negotiated, before final commitments are made.
FSM also enables comparison of applications and projects based on their size. Productivity rates for applications of a similar attribute profile can be compared for benchmarking and improvement purposes. Productivity rates from past projects can also be used to predict effort, once a project's Functional Size has been determined. FSM is used to size software work product. This work product is the output of software new development and enhancement projects. It is the software which is migrated to the production application at project implementation.
0コメント