Mark-II Estimation

What is Mark-II Estimation

It is a size estimation technique of a software product. It belongs to the class of functional point group of measurements. Traditionally, software size was measured in terms of the number of source code lines (SLOC or KLOC). The amount of SLOC had a direct association with the relative size of software. Mk II is also known as MK II Function Point Analysis. Developers are responsible to generate an accurate estimate of the effort and cost required to deliver a software product, and also to compare different solutions , technology, and tools to assess effort and cost estimate. In order to carry out such activities, they must be able to determine the 'what', 'how much' aspects of the software product.

Why Functional Size Measurement ?

Functional size measurement technique is the only ISO standardised technique, that enables measuring the size of the Users Functional Requirements. Functional requirements are of an independent nature , hence it can measured irrespective of any other non-functional or technical requirements. It is therefore an efficient technique to measure the effective of a software product.

Mark II FPA counting rules :

  • Define the boundary count -The logical line that separates a user from the system is called the boundary. It simply determines the rules for user's entry and exit in the system.
  • Identify logical transactions -The number of logical transactions are counted.
  • Identify and Categorise Data Entity Types -Entities are the components that convey a meaningful information to the user.
  • Count the input data element types, the data entity types referenced and output data element types.It specifies the rules to enlist the total number of input types its references and prepare a complete report of the same.
  • Count the functional size -Now when the objects in the system and the transactions are identified, they can be considered for finding the functional size of the system. The functional size of the system is counted as the number of input/exit transactions between the user and the system.

Currently there are five methods approved by the International Organisation for Standardisation. Theses are as follows :

  • COSMIC-FPP - As specified by ISO/IEC 19761:2009 - a functional size measurement method.

  • IFPUG CPM - As specified by ISO/IEC 20926:2009
  • MK II Function Point Analysis - ISO/IEC 20968:2002
  • NESMA FPA method - ISO/IEC 24570:2005 - Definitions and counting guidelines for applying Function point analysis.
  • FISMA FSM -ISO/IEC 29881:2008 - functional size measurement method.

Guidelines as recommended by ISO :

To be able to apply the most appropriate method, ISO has layed down few key principles, that one must abide by while choosing a method.

  • Applicability to the domain of software that we need to measure - Various applications that has data as the core, like Management Information Systems, CRM, Asset Management etc., may adopt IFPUG method.
  • Availability of equivalent industry data - If an organisation needs industry data for input estimates or comparison of productivity, then it is a factor worth considering. COSMIC method is becoming popular in such a scenario.
  • Availability of training and FSM tools - Most of the popularly used tools have been written to measure that makes use of the IFPUG method. An example of such a tool is SCOPE(a project sizing software). As its use increases, the use shall extend to COSMIC method adoption.
  • Availability of trained and experienced certified Metrics experts - The training of COSMIC method is confined to Europe, North America and Australia. However there are quite a good number of trained and certified IFPUG experts.

ThinkSys Advertisement
ThinkSys Advertisement

Issues faced in managing Functional Size Results :

  • Results are not easy to check for correctness or completeness - There is no definite way to keep a track of the functional requirements with respect to the model. An expert working on a specific model cannot omit the measured results as this may lead to underestimation of effort and cost invested into the project.
  • Size calculation formulas are prone to corruption - This requires a precise observation and calculative approach to understand how and in which scenario a specific formula needs to be applied. It requires a great amount of experience and the right acumen, and therefore an inexperienced person tends to commit a mistake.
  • Significant time is wasted on every measurement as there is little opportunity for re-use of previous measurements - The measurement criteria applied or used in some of previous projects can not be referenced for a new project as it may result in erroneous outcomes. There is possibly no way of doing that, because as a new project starts, a new spreadsheet is prepared to maintain the records, therefore, referring to the old records can provide inconsistent and duplicate results.
  • Baseline Sizes are quickly out of date - If a base lined measurement has been completed for a project, then a new request for change may not take place as that may affect a project's current baseline size.
  • Configuration control of multiple concurrent projects is very difficult - One tool should be devoted to a single project. When multiple projects are applied to the same application, then developers try to analyse the impact of measurement of their project. In such a case, it becomes bit tricky to cross reference the results of each project.

ThinkSys Advertisement

Get New Content Update
Popular Posts
Dec 07, 2020
Dec 07, 2020
Dec 07, 2020


ThinkSys Advertisement


App development ad thinksys