Value adjustment factors in software development

In order to analyze the various methods used to value computer software, it is useful to start with a definition of software. Computer software is sometimes defined as the programs that tell the computer what to do; the broadest definition is that software includes everything that is not hardware. The definition typically used in valuing software, at least as an operational component of a going-concern business enterprise, reflects the software's function in satisfying its users' needs.

Thus, software is the entire range of activities—including feasibility studies, planning and requirements, product design and architecture, file structures and layouts, coding, testing, integration and implementation—that permit delivery of computer processing services to the end-users.

Valuation analysts often use software engineering models to estimate the replacement cost of software systems when using the cost approach to value. These models were created to assist software developers in estimating the effort, time and human resources needed to complete a software project. That is, the development time and development cost of the subject software is estimated by reference to a large database of actual software development projects where the actual development times were carefully monitored.

In the COCOMO model, this database of actual software development projects was used to derive the equations and cost drivers. In the SLIM model, the equations are based on the study of actual development projects, and key variables may be assigned using projects in the database with characteristics similar to those of the subject system.

Both models calculate an estimate of effort to develop a software system in terms of person-months. To estimate the cost to develop that system, the number of months should be multiplied by a current cost as of the valuation date per person-month. The cost per person-month is a comprehensive or "fully loaded" cost that includes the average base salary of the development project team members and other factors.

These other factors include, but are not limited to, perquisites, payroll taxes e. This cost estimation method projects the amount of effort required to create the subject software, taking into consideration the size of the programs, the program characteristics and the resource constraint environment in which they are to be developed.

That basic model estimates the number of person-months to develop a software product as a function of the metric called "delivered source instructions. This person-month estimate includes all phases of the development from product design through integration and testing, including documentation. Delivered source instructions are source program lines of code including job control language, data declarations and format statements—but excluding programmer comment lines, unmodified utility software and, generally, non-delivered support software.

The basic COCOMO model allows for three different modes of software development, with a specific effort equation provided for each. The software development modes characterize three general environments in which software is developed: the organic, semidetached and embedded modes.

Organic projects are defined as small in terms of number of delivered source instructions under 50, and project team size. The project team has extensive experience working with related software systems.

Additionally, organic projects do not require complicated algorithms. Organic projects are developed in a familiar and stable environment and are not developed under severe time constraints. Examples of organic systems are scientific models, business models and batch-type data reduction. Embedded projects are defined as large and are characterized by tight hardware, software and operational constraints.

Large project teams and complex data processing architectures and algorithms are usually involved in the embedded mode development environment. Examples of embedded systems are avionics and ambitious command-control systems.

The semidetached mode in an intermediate software development environment between the organic mode and the embedded mode. Various parameters for the company are given in the table below. Which one of the following is a functional requirement?

Suggested Test Series. Suggested Exams. More Software Engineering Questions Q1. The cyclomatic complexity of each of the modules A and B shown below is What is the cyclomatic complexity of the sequential integration shown on the right hand side? The following is the comment written for a C function. It handles four different kinds of cases.

Only in case ii and iii , the stored roots are valid. Otherwise 0 is stored in the roots. The function returns 0 when the roots are valid and -1 otherwise.

He comes up with the following test cases, many of which are redundant. The following figure represents access graphs of two modules M1 and M2. The filled circles represent methods and the unfilled circles represent attributes. If method m is moved to module M2 keeping the attributes where they are, what can we say about the average cohesion and coupling between modules in the system of two modules?

What is the reliability of the module if the probability of success is 0. All that being said, I'll give you the quick VAF introduction so you can make a decision on your own. If nothing else, I find it nice that someone has taken the time to come up with these 14 categories. It helps my thinking in other areas. These GSCs represent characteristics of the application under consideration. Each is weighted on a scale from 0 low to 5 high.