Software Effort Estimation Quiz

Study Notes

Software projects require accurate effort estimations for successful delivery. Factors like agreed functionality, on-time completion, adherence to budget, and required quality affect project success.

Successful projects deliver agreed-upon functionality, are completed on time, meet the agreed cost, and maintain the required quality.

Parkinson's Law states that work expands to fill the available time. This means that underestimating can lead to a longer project duration. Likewise, overestimating can also lead to longer project times.

Weinberg's Zeroth Law of reliability asserts that a software project not required to meet a reliability requirement can meet any other requirement.

Bottom-up: This method breaks projects into smaller components; it's suitable when past project data is unavailable. It is time-consuming.
Top-down: This method calculates an overall estimate initially; it is based on past project data and often uses project cost drivers. This is efficient but can lead to oversimplification of the project elements.
Steps of Bottom-up:
- Decompose the project into smaller, manageable components.
- Determine the effort required for each component.
- Sum component efforts to provide the overall project estimate.
Taxonomy of Estimating Methods: Different methods include: bottom-up (activity-based, analytical); parametric or algorithmic models, including function points; expert opinion (sometimes considered "guessing"); and analogy (case-based, comparative).

Parametric models utilize historical data, calculating effort based on a project's characteristics. Examples include COCOMO (utilizing lines of code), and function points (analyzing system characteristics like inputs, outputs, and data items to create a model based on similar past project estimation experience).
COCOMO81: A model based on industry productivity standards (e.g., database size, programmer experience), adjusted according to complex factors, enabling organizations to benchmark productivity.. The effort is calculated as 'C * size^k’ where C and k are constants for organic, semi-detached, and embedded systems, and system size is measured in thousands of lines of code (kloc). System type will influence the appropriate constants (C, k) that should be used.
Examples of system characteristics in parametric models are:
- Number of screens x 4 hours
- Number of reports x 2 days
- Number of entity types x 2 days

Function points, particularly Mark II, are for estimating the size of information systems, not effort. They are calculated from a software system's characteristics, rather than from lines of code.
Function points are used to estimate the size of an information system that is reflected in the number of data entities, the number of input/output transactions, and the number of files/records. The COCOMO model is also suited to estimate lines of code but can be adjusted to estimate other factors like effort and time-to-market.
FPs are useful for estimating complexity of an information system.

Function points Mark II and IFPUG function points are originally designed for information systems; COSMIC FPs extend the concept to embedded systems which are usually layered.

A layered software system consists of layers that communicate with each other to provide services and functionality. The example shows how processes involving persistent storage are involved at a peer level or a higher level of software.

COSMIC Functional size units (Cfsu) focus on counting data movements into and out of software components. Entries and exits are treated as one. Reads and writes of data are also treated as one.

Review estimates through critical questions, including:
- Size drivers of the tasks
- Productivity rates in use
- References to previous similar projects.
- Verification of the productivity rates themselves.