Software sizing

Last updated

Software sizing or software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities (such as estimating or tracking). Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.

Contents

Background

Software sizing is different from software effort estimation. Sizing estimates the probable size of a piece of software while effort estimation predicts the effort needed to build it. The relationship between the size of software and the effort required to produce it is called productivity.

For example, if a software engineer has built a small web-based calculator application, we can say that the project effort was 280 man-hours. However, this does not give any information about the size of the software product itself. Conversely, we can say that the application size is 5,000 LOCs (Lines Of Code), or 30 FPs (Function Points) without identifying the project effort required to produce it.

Functional software-sizing methods

Historically, the most common software sizing methodology has been counting the lines of code written in the application source. Another approach is to do Functional Size Measurement, to express the functionality size as a number by performing function point analysis. The original sizing method is the IFPUG. The IFPUG FPA functional sizing method (FSM) has been used successfully – despite being less accurate in estimating complex algorithms and being relatively more difficult to use than estimating lines of code. Adaptations of the original Functional Size Measurement methodology have emerged, and these standards are: COSMIC Function Points, Mk II Function Points, Nesma Function Points, and FiSMA Function Points. Other variants of these standards include Object-Oriented Function Points (OOFP) and newer variants as Weighted Micro Function Points, which factor algorithmic and control-flow complexity.

The best Functional Sizing Method depends on a number of factors, including the functional domain of the applications, the process maturity of the developing organization and the extent of use of the FSM Method. [1] [2] There are many uses and benefits of function points [3] beyond measuring project productivity and estimating planned projects, these include monitoring project progress and evaluating the requirements coverage of commercial off-the-shelf (COTS) packages.

Other software sizing methods include Use Case-based software sizing, which relies on counting the number and characteristics of use cases found in a piece of software, and COSMIC functional size measurement, which addresses sizing software that has a very limited amount of stored data such as 'process control' and 'real time' systems.

Both the IFPUG Method and the COSMIC Methods are ISO/IEC standards.

Non-functional software-sizing method

The IFPUG method to size the non-functional aspects of a software or component is called SNAP, therefore the non-functional size is measured by SNAP Points. The SNAP model consists of four categories and fourteen sub-categories to measure the non-functional requirements. Non-functional requirement are mapped to the relevant sub-categories. Each sub-category is sized, and the size of a requirement is the sum of the sizes of its sub-categories. The SNAP sizing process is very similar to the function point sizing process. Within the application boundary, non-functional requirements are associated with relevant categories and their sub-categories. Using a standardized set of basic criteria, each of the sub-categories is then sized according to its type and complexity; the size of such a requirement is the sum of the sizes of its sub-categories. These sizes are then totaled to give the measure of non-functional size of the software application.

Additional information

Several software quality standards mandate the use of a valid sizing method as part of the organization's standard software engineering life cycle. For instance, Capability Maturity Model Integration (CMMI) poses such a requirement. An organization cannot be appraised (certified) as CMMI level 2 or level 3 unless software sizing is adequately used.

See also

Related Research Articles

ISO/IEC 15504Information technology – Process assessment, also termed Software Process Improvement and Capability dEtermination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions. It is one of the joint International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standards, which was developed by the ISO and IEC joint subcommittee, ISO/IEC JTC 1/SC 7.

In the context of software engineering, software quality refers to two related but distinct notions:

<span class="mw-page-title-main">ISO/IEC 9126</span> Former ISO and IEC standard

ISO/IEC 9126Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.

Quality management ensures that an organization, product or service consistently functions well. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality. Quality control is also part of quality management. What a customer wants and is willing to pay for it, determines quality. It is a written or unwritten commitment to a known or unknown consumer in the market. Quality can be defined as how well the product performs its intended function.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

In functional safety, safety integrity level (SIL) is defined as the relative level of risk-reduction provided by a safety instrumented function (SIF), i.e. the measurement of the performance required of the SIF.

NFR need a framework for compaction. The analysis begins with softgoals that represent NFR which stakeholders agree upon. Softgoals are goals that are hard to express, but tend to be global qualities of a software system. These could be usability, performance, security and flexibility in a given system. If the team starts collecting them it often finds a great many of them. In order to reduce the number to a manageable quantity, structuring is a valuable approach. There are several frameworks available that are useful as structure.

IEC 61508 is an international standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.

The function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost of a single unit is calculated from past projects.

The International Function Point Users Group (IFPUG) is a US-based organization with worldwide chapters of Function point analysis metric software users. It is a non-profit, member-governed organization founded in 1986.

Software measurement is a quantified attribute of a characteristic of a software product or the software process. It is a discipline within software engineering. The process of software measurement is defined and governed by ISO Standard ISO 15939.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

The MK II Method is one of the software sizing methods in functional point group of measurements. This is a method for analysis and measurement of information processing applications based on end user functional view of the system. The MK II Method is one of five currently recognized ISO standards for Functionally sizing software.

Use case points is a software estimation technique used to forecast the software size for software development projects. UCP is used when the Unified Modeling Language (UML) and Rational Unified Process (RUP) methodologies are being used for the software design and development. The concept of UCP is based on the requirements for the system being written using use cases, which is part of the UML set of modeling techniques. The software size (UCP) is calculated based on elements of the system use cases with factoring to account for technical and environmental considerations. The UCP for a project can then be used to calculate the estimated effort for a project.

SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of the software derived by quantifying the non-functional user requirements for the software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software user requirements. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Process (SNAP) Assessment Practices Manual” (APM) now in version 2.4. Reference “IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements,” published October 19, 2019. Also reference ISO standard “Software engineering — Trial use standard for software non-functional sizing measurements,”, published October 2021. For more information about SNAP please visit YouTube and search for "IFPUG SNAP;" this will provide a series of videos overviewing the SNAP methodology.

<span class="mw-page-title-main">Tudor IT Process Assessment</span> Process assessment framework

Tudor IT Process Assessment (TIPA) is a methodological framework for process assessment. Its first version was published in 2003 by the Public Research Centre Henri Tudor based in Luxembourg. TIPA is now a registered trademark of the Luxembourg Institute of Science and Technology (LIST). TIPA offers a structured approach to determine process capability compared to recognized best practices. TIPA also supports process improvement by providing a gap analysis and proposing improvement recommendations.

COSMIC functional size measurement is a method to measure a standard functional size of a piece of software. COSMIC is an acronym of COmmon Software Measurement International Consortium, a voluntary organization that has developed the method and is still expanding its use to more software domains.

The Simple Function Point (SFP) method is a lightweight Functional Measurement Method.

References

  1. ↑ Guidelines on how to choose an FSM Method
  2. ↑ Guidance on How to Choose a Functional Size Method - Pam Morris Total Metrics - Function Point Resource Centre see ISO/IEC 14143-6: - SOFTWARE ENGINEERING — SOFTWARE MEASUREMENT — FUNCTIONAL SIZE MEASUREMENT — PART 6: GUIDE FOR USE OF ISO/IEC 14143 SERIES AND RELATED INTERNATIONAL STANDARDS
  3. ↑ Uses and Benefits of Function Point Counts - Pam Morris Total Metrics - Function Point Resource Centre, PDF
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.