Browse Prior Art Database

Method to Provide a Software Overview Assessment

IP.com Disclosure Number: IPCOM000034589D
Original Publication Date: 1989-Mar-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 3 page(s) / 17K

Publishing Venue

IBM

Related People

Breyfogle, FW: AUTHOR

Abstract

A process is described which addresses a strategy to determine quickly if a software product will meet most of its intended function. Conventional strategies for testing software products do not, in general, give emphasis to assessing software from a "big picture" point of view. Documented software-testing strategies usually emphasize evaluating software at the "path" and "state" level. This testing can be very important for software reliability; however, often the "big picture" applications are lost. In addition, whenever a software product is developed at a vendor, "path" testing is not usually performed by the procurer; the procurer may often evaluate only a few "typical" applications. Basically, the purchaser is at risk that the vendor developed/tested the product satisfactorily.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 3

Method to Provide a Software Overview Assessment

A process is described which addresses a strategy to determine quickly if a software product will meet most of its intended function. Conventional strategies for testing software products do not, in general, give emphasis to assessing software from a "big picture" point of view. Documented software-testing strategies usually emphasize evaluating software at the "path" and "state" level. This testing can be very important for software reliability; however, often the "big picture" applications are lost. In addition, whenever a software product is developed at a vendor, "path" testing is not usually performed by the procurer; the procurer may often evaluate only a few "typical" applications. Basically, the purchaser is at risk that the vendor developed/tested the product satisfactorily. This risk extends to software interface dependencies, which can be difficult to assess completely during initial product definition and implementation. Risk levels can, in general, be high, especially as software applications become more complex. With both "in house" and vendor-developed software, problem escapes are often caused by customer situations that are "unusual." This new process will give emphasis to "catching" these "unusual" problems that can, in reality, occur quite frequently and be very difficult to both diagnose and "fix" in the field. A "factorial" matrix design approach is used to create the experimental test trial combinations; however, the number of trials and variable assignments differ from conventional techniques. This new process is unique in that all the following are considered within one experiment: software verbs, error conditions, communication networks, configurations, and program handling. The method includes the following steps: 1. Make a list which includes:

all software verbs, in general, without parameter

designations,

all error conditions that need to be considered,

all communication networks, and

minimum and maximum number of network sessions,

2. List all assumptions.

3. Define the number of levels for each of the variables. It is

desirable to construct the variables so that the

levels between the variables are physically

possible in any combination. If this is not

reasonable, the test matrix trials

will later need some alteration to make all trials

realistic.

Programming details should be specific during this

definition.

4. Assign binary variable level designations using alphabetic

designations. If there are only two levels, then

only one

letter is needed; however, if there are four

levels, two

1

Page 2 of 3

letter designations are necessary. In the case of

eight

levels, three letter designations are necessary. If the

number of levels is not 2n, where n= 1,2,3, etc, some levels

will need to be repeated.

Example for steps 3 and 4 follow. The following variables may be appropriate to test a communication software package. Appropriate verbs unique with this particular...