Software requirements metrics and evaluation process

Details Software requirements metrics and evaluation process Software requirements metrics and evaluation process

1998-10-05

2004-03-30

Hong, Stephen S. (Department: 2178)

Data processing: presentation processing of document, operator i

Presentation processing of document

Layout

C715S252000, C705S002000, C705S014270

Reexamination Certificate

active

06715130

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to estimation of factors associated with the economic costs of development of desired products by analysis of descriptions of features of the product, such as the functional content of software, and, more particularly, to a system and metric for quantitative evaluation of customer requirements for a desired product, especially a software application.
2. Description of the Prior Art
The use of computers for conducting various enterprises and activities has become substantially universal and the comparative advantage of computer use, itself, has been correspondingly diminished. Accordingly, at the present time, most significant advantages must accrue from closely matching software applications to the specific activity to be performed. Such matching of activities with facilities of a software application not only provides supports and enhancements for such activities (e.g. database management and access, archival records, decision support, etc.) but also ensures relatively optimal performance of the computer system, thereby reducing obsolescence of data processor hardware. For many computer installations, hardware costs for acceptable performance may be prohibitive without closely matching software functions to supported activity.
Matching of application capabilities and facilities generally begins with an analysis of the activities to be supported which may then be transformed into a listing of the functions the computer or data processor must perform, generally referred to as “requirements”. The list of requirements will generally be refined through a series of iterations, each of increased detail until a final, fully detailed Software Requirements Specification (SRS) is achieved. A parallel process for an article of manufacture might comprise a sequence of an initial notation of an idea, a rough sketch, additional views of the object, sketches of parts and, eventually detailed drawings and specifications of each part or the article.
Commercial off-the-shelf software is often available to supply a set of functions meeting the needs of a relatively wide variety of potential customers while not all or even a majority of the functions may be needed by any given user. However, for many activities such as air traffic control and complex decision support systems for manufacture of certain types of goods, the potential customer base may be extremely limited while very complex functions and the management of access to potentially vast databases may be required within stringent processing time constraints. In these cases, the matching process may begin with a statement of a basic concept or a request for information (RFI) from a potential customer to a software company.
In the latter cases, the writing of new software code is generally required and the application extensively developed and refined over an extended period although some existing applications may be incorporated therein. The software developer will thus need to be able to estimate the cost of services over the course of development of software to meet a customer's needs although those needs may initially be only broadly and conceptually defined. The customer will often approach several software developers concurrently with a request for proposal (RFP) and the developer must be able to estimate costs with sufficient accuracy to be competitive with other software developers while seeking to avoid economic loss in regard to services provided to the customer and the final product and project price.
Accordingly, providing an accurate estimate of the cost of a project to the customer assumes a very great importance while the information from which the estimate is to be made often remains conceptual and lacking in detail. The potential for error in estimating cost can be seen to be especially great when it is considered that some specially developed applications, when completed, can comprise many hundreds of thousands of lines of code for which the underlying necessary technical concepts and even hardware may not exist when the project is initiated. Moreover, technical approaches to required functions may need to be not only developed but implemented in an efficient manner and numerous versions of lengthy sections of code may be written and rewritten many times before adequate performances is achieved. It is not unusual to employ several hundred skilled programmers full-time for an extended period, often exceeding several months, to complete a specially developed software application of a complexity which is becoming increasingly common.
An estimate of the quantitative functional content of a proposed software system is the foundation for the estimate of the development effort, cost, staffing, schedule and the like associated with the development of the software system. The quantitative functional content estimate, whether it is in function points, lines of code, object points or other functional proxy, is the primary input to the cost estimation process. This process may involve the use of commercially available parametric cost models such as the Constructive Cost Model (COCOMO, Barry Boehm, University of Southern California), Software Life Cycle Management (SLIM, Quantitative Software Management, McLean, Va.) or simply utilize the development organization's local metrics to estimate cost, schedule and staffing. In any costing process, a quantitative functional content estimate is necessary before the cost estimation process can proceed.
It is known that a computation or analysis methodology commonly referred to as function point assessment can yield quantitative functional content estimates of good accuracy for software development. Function point assessment is largely based on five types of entities: External Inputs (RI), external Outputs (EO), External Queries (EQ), External Interface Files (RIF) and Internal Logical Files (ILF). Each of these types of entities corresponds more or less closely with a quantitative amount of functionality and internal compatibility which is to be achieved in the context of other entities.
This methodology provides a numerical measure or functional proxy representing the amount of function to be developed for inclusion and integration within an application. (A function point can be considered as approximating a fixed number of lines of source code in a given programming language and is thus a good measure of programming costs once other cost sources such as the development of solutions to technical problems are resolved.) The function point assessment technique is well-established as the current benchmark against which any other estimation technique must be compared in terms of accuracy.
However, the function point assessment process assumes and requires mature and detailed documentation (e.g. a detailed software requirements specification (SRS)) and a clear technical solution determined for functionalities to be provided, neither of which is ordinarily available during initial stages of a project. In other words, the function point assessment can be accomplished only when the full functionality of the application is known and well-defined and documented and the technical solutions which will be used in developing the functions are known and established to be effective in the context of the remainder of the application.
Otherwise, the state of the art can be summarized as one of two basic approaches. The so-called Delphic process involves reading and study of a document, regardless of quality, maturity or level of detail by experienced personnel and assessment in a largely prospective manner, based on generally perceived similarities to past experience, to result in some credible forecast of possible functional content and resulting associated development cost. The other so-called linear approach involves evaluation of a somewhat higher level of documentation (but of less detail and maturity than an SRS), counting the number of required functions and a linear approximation of associated funct

Affiliated with

Also associated with

Rating

Software requirements metrics and evaluation process does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Software requirements metrics and evaluation process, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Software requirements metrics and evaluation process will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3251289