Methodology for developing interactive systems

Details Methodology for developing interactive systems Methodology for developing interactive systems

1999-10-12

2004-11-23

Chawan, Vijay (Department: 2654)

Data processing: speech signal processing, linguistics, language

Speech signal processing

Application

C704S270000, C704S257000, C704S270100

Reexamination Certificate

active

06823313

ABSTRACT:

BACKGROUND OF THE DISCLOSURE
Description of Related Art
FIG. 1
is a diagram of a typical software development lifecycle, not necessarily limited to speech recognition systems. At block
10
, a software design team defines the requirements applicable to a given computer software system. The term “team” here refers to either an individual designer or to a group of designers working in concert. These requirements drive the design of the software system, as illustrated in block
12
. After designing the system, the design team develops and implements a prototype system to fulfill those requirements, as shown in block
14
. If the development stage reveals any design errors, the team returns to block
12
to correct those design errors. Typically, the design and development stages illustrated in blocks
12
and
14
entail significant investments of time and money.
At block
16
, the prototype system is tested to ensure that it meets the requirements defined in block
10
. In some circumstances, the testing shown in block
16
reveals design errors in the prototype system, and the design team must refine the system as shown in block
18
to identify fixes for those design errors. To identify these fixes, the design team may have to address either the design or the implementation of the system, shown in blocks
12
and
14
, respectively. Once correct fixes are identified, the team returns either to block
12
or to block
14
to implement these fixes, depending on whether the system design (block
12
) or the system implementation (block
14
) must be addressed. The process is repeated until testing reveals that the system meets all applicable requirements. At this point, the system is considered completed, as shown in block
20
.
As a general rule, whether developing speech recognition systems or other types of software, the later in the project development lifecycle that a design error is found, the more expensive it is to fix that design error. This general rule holds not only because fixing one design error may have a “ripple effect” of creating additional design errors, but also because the system must be regression tested after the fix to ensure that fixing the first design error did not create other design errors. For example, if it costs a certain amount of money, X dollars, to fix a design error located during the design stage (block
12
), it generally costs three times that amount of money, 3X dollars, to fix that same design error located in the development stage (block
14
). Furthermore, if that same design error is initially located in the test stage (block
16
), it costs about nine times that amount of money, 9X dollars, to fix that design error. Clearly, from a project management standpoint, it is advantageous to locate design errors as early in the project development lifecycle as possible. The cost of finding and fixing a design error grows exponentially in relation to the phase of a project in which the design error is located.
One drawback to the paradigm shown in
FIG. 1
is that it does not typically locate system design errors early in the project lifecycle, that is before substantial resources, including time and money, have already been expended on the project. Note that the testing activities shown in block
16
typically do not occur chronologically until after the design and development stages, shown in block
12
and
14
respectively, have been completed to provide a functioning prototype. In more traditional software engineering methodologies, the design underlying the software system cannot be rigorously tested until the functioning prototype has been implemented. To implement such a prototype entails a significant investment of time and money. Accordingly, by the time the prototype system is ready for testing (block
16
), significant time and money have already been invested in designing and developing the prototype system. Typically, the bulk of system design errors are located during the test stage (block
16
), and as discussed above, design errors located during this stage are the most expensive to fix, because the design and development stages are already thought to be substantially complete.
In light of the above disadvantages of the software development lifecycle shown in
FIG. 1
, it would be advantageous to provide the capability to test the design before implementing a functioning prototype and before the design and development stages are substantially completed or have even begun. In this manner the testing step is moved earlier in the development methodology, where design errors are cheaper to fix. Accordingly, a need exists in the art for a software design methodology that promotes the location of system design errors relatively early in the project lifecycle, when such design errors are relatively inexpensive to fix. In addition to reducing the cost of locating and fixing errors, such a methodology would also reduce overall project cost in terms of both time and money. However, such a methodology would further provide the ability to evaluate designs using correct and appropriate physical senses, would improve the odds of overall project success, and would improve the chances of ultimate customer acceptance and understanding.
SUMMARY
The present invention is directed to a method of developing a computer-based dialogue interface for an automated or computerized system. The dialogue interface is disposed between the automated system and an end user, with the dialogue interface receiving input from the end user and providing output to the end user in response to the input. In an illustrative embodiment, the method comprises the following steps. A system designer(s) defines a plurality of requirements applicable to the dialogue interface. The dialogue interface is then designed to meet these requirements. The automated system is simulated with at least a first person, and the end user is simulated with at least a second person. The dialogue interface is evaluated by facilitating an interaction between the first and the second persons through the dialogue interface. Based on the interaction between the first and the second persons, the dialogue interface is evaluated. Based on the evaluation of the dialogue interface, the dialogue interface is refined.
After performing the above steps, the automated system is then developed based upon the dialogue interface.


REFERENCES:
patent: 5493608 (1996-02-01), O'Sullivan
patent: 5730603 (1998-03-01), Harless
patent: 5774860 (1998-06-01), Bayya et al.
patent: 5794204 (1998-08-01), Miyazawa et al.
patent: 5983190 (1999-11-01), Trower et al.
patent: 6044347 (2000-03-01), Abella et al.
patent: 6321198 (2001-11-01), Hank et al.
patent: 6330539 (2001-12-01), Takayama et al.
patent: 6418440 (2002-07-01), Kuo et al.
patent: 6604094 (2003-08-01), Harris
patent: 6665640 (2003-12-01), Bennett et al.

Affiliated with

Also associated with

Rating

Methodology for developing interactive systems does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Methodology for developing interactive systems, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methodology for developing interactive systems will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3302167