| Systems and methods for defining a simulated interactive web page -> Monitor Keywords |
|
|
 
Systems and methods for defining a simulated interactive web pageRelated Patent Categories: Data Processing: Software Development, Installation, And Management, Software Program Development Tool (e.g., Integrated Case Tool Or Stand-alone Development Tool), ModelingSystems and methods for defining a simulated interactive web page description/claimsThe Patent Description & Claims data below is from USPTO Patent Application 20070168931, Systems and methods for defining a simulated interactive web page. Brief Patent Description - Full Patent Description - Patent Application Claims
[0001] This application is a continuation application of U.S. application Ser. No. 10/763,080, filed Jan. 22, 2004, which is a continuation application under 35 U.S.C. .sctn. 365(c) and 35 U.S.C. .sctn. 120 of prior PCT application PCT/U502/23816, filed Jul. 26, 2002, which was published as WO 03/010684 A1 on Feb. 6, 2003 under PCT Article 21(2) in English, which claims the benefit under 35 U.S.C. .sctn. 119(e) of U.S. Provisional Application No. 60/308,052, filed Jul. 26, 2001, the entireties of which are hereby incorporated by reference herein. [0002] This application is related to (i) copending application entitled SYSTEM AND PROCESS FOR GATHERING, RECORDING AND VALIDATING REQUIREMENTS FOR COMPUTER APPLICATIONS, Ser. No. 10/484,541, which is the National Phase of prior PCT application PCT/U502/23816 filed Jul. 26, 2002; to (ii) copending application entitled SYSTEMS AND METHODS FOR COLLABORATIVE PROGRAMMING OF SIMULATIONS OF COMPUTER PROGRAMS, Ser. No. 10/763,012, filed Jan. 22, 2004, which is also a continuation application of prior PCT application PCT/U502/23816; and to (iii) copending application entitled SYSTEMS AND METHODS FOR A PROGRAMMING ENVIRONMENT FOR A SIMULATION OF A COMPUTER APPLICATION, Ser. No. 10/762,428, filed Jan. 22, 2004, which is also a continuation application of prior PCT application PCT/US02/23816. TECHNICAL FIELD [0003] The present invention is directed to a system and process for gathering, recording and validating requirements for computer applications in the fields of requirements analysis for computer application development and of computer application development. [0004] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. INDUSTRIAL APPLICABILITY [0005] The present invention has applicability in the field of design and development of computer software applications for businesses and other entities, particularly concerning large, complex systems adapted for networks, including private networks as well as public networks such as the Internet. BACKGROUND OF THE INVENTION [0006] With the increasing complexity involved in the development of computer programs that embody very sophisticated business logic, specification of the requirements of these programs before they are actually built, i.e., programmed into computer readable code is important to timely and cost-effective production of these systems. [0007] As organizations are forced to do more with less, the need to deliver such applications on-time and on-budget without sacrificing quality presents a bigger challenge than ever before. One of the major problems in these fields is system definition, i.e., the effective identification of accurate, complete and unambiguous requirements for the system or application. This is especially true of applications used on the Internet. These applications must meet requirements related not only to graphic design, content and usability, but also related to complex scenarios of user system interactions that are not complete and accurate requirements from outset and may not even be documented before starting the application design. [0008] Traditional software development falls typically into several main disciplines. The first is known as the "waterfall" software development life cycle approach. The second approach attempts to improve the effectiveness of the waterfall approach by introducing prototypes into the development lifecycle early in the development cycle. Each of these approaches is associated with significant problems. [0009] The waterfall approach is a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. This phase of development is analogous to the flow of water over a waterfall; it cannot flow back to the top of the waterfall. In the waterfall design approach, the requirements gathering phase typically results with capture of requirements on paper documents. Typically, the system designers generate a paper-based design from the paper-based requirements. The system developers then interpret the paper-based design and convert it into executable computer code. Typically, the executable code is then delivered to the testers, who then evaluate the code to determine if the resulting computer application meets the requirements. [0010] While waterfall development allows for departmentalization and managerial control, it does not allow for much reflection or revision. Iterations of the design process require iterations of the entire process. However, once an application is in the testing stage, it is very difficult to go back and change something that was not well thought out in the concept stage. Also, typically, problems are not discovered until system testing, and requirements must be fixed before the system is designed. Requirements evolution makes the development method unstable. Often during the design and code writing phases, requirements inconsistencies, missing system components and unexpected development needs are discovered. Also, system performance cannot be tested until the system is almost coded, and under-capacity may be difficult to correct. For these reasons the standard waterfall model has been associated with the failure or cancellation of a number of large systems. [0011] Known alternatives to the standard waterfall design approach include modified waterfall approaches that include those that start with a very rough notion of the system and become more detailed over time, analogous to going over several smaller waterfalls (spiral waterfall design); and those that include overlapping phases and sub-projects (modified waterfalls). [0012] Other known design approaches includes the staged delivery approach, in which the designer reviews the concept, requirements analysis, and architectural design phases, and then implements these phases, shows them to the customer as the components are completed, and then goes back to the previous phase(s) if needed. [0013] All of these waterfall type approaches suffer from the same or similar problems, however. The iterative approach through the phases, even when overlapped, results in static requirements being interpreted into static designs and developments. Because the requirements for most systems are not well understood in the beginning, the costs for development often become excessive and delivery schedules originally estimated must be revised. Finally, because complex systems typically are not well understood in terms of their actual implemented behaviors, it is only through actual interaction with the system that the system designers and business analysts truly begin to understand what has been built. Although the lessons learned may be valuable during waterfall implementations, they cannot easily be taken advantage of, due to the prohibitive costs of re-factoring the designs and implementations to reflect the new requirements that spring from these lessons. [0014] The second general approach, the prototyping of critical parts of the application, was developed, partly in response to the problems associated with the waterfall and modified waterfall approaches. As used herein, the term prototype, and its variations, in the context of the design of computer applications means the use of some form or stage of application code, or the use of static images to represent computer screen display. [0015] The prototyping of critical parts, referred to sometimes herein as code prototyping, also was developed in response to awareness in the field of the invention that software product development tends to move along four paths: (1) ideas to product; (2) low technology to high technology; (3) drawings to code; and (4) appearance and behavior to performance. In the code prototyping approach, a prototype code is built to test the results of the planning phase, during which the developers attempt to understand the users and the users' needs and how those were to be addressed in the software application. The prototype code is then measured to see how the user reacts and understands the developers work, and is analyzed to see which parts of the prototype are doing well and which parts are not. In this prototyping approach, the prototype is actually code that is intended to accomplish the intended purpose of designated parts of the overall software application, and is therefore referred to herein as a "coded prototype." [0016] The prototyping approach also has been associated with numerous problems, foremost among them is that prototypes are typically written in computer languages that only programmers can understand and use. Thus the prototypes are still developed as traditional computer programs, by programmers. This has several drawbacks. The first drawback is that business analysts, who are the people most likely to understand the needs and desires for the computer application, cannot develop the prototype without reliance on computer programmers, and must translate and communicate these needs and desires to computer programmers in order to have them construct the prototype. This communication is traditionally inefficient and translation errors tend to be introduced because of the differences in the interpretation of the needs and desires for the prototype between two constituencies with differing backgrounds and skill sets. Second, in many organizations, skilled programming resources are preferentially assigned to fixing existing computer systems or completing development of systems that are soon to be placed in production. Thirdly, programming resources need potentially expensive hardware and software tools to accomplish their work. Fourthly, because prototypes are frequently constructed using the same infrastructure that the eventual application will be deployed upon, prototyping efforts are frequently delayed until strategic hardware acquisition, development software acquisition and training have been completed. [0017] Yet another problem with prototyped systems is that they tend to become a replacement for actual development of the envisioned system. There is a tendency to attempt to field a completed, or near-completed prototype. Because the programmers were originally building just a subset of the system for demonstration purposes, short cuts typically are taken in this phase that lead to systems that do not scale well and have significant performance problems. [0018] Yet another problem with coded prototypes is that they suffer from poor documentation, often because the prototype and the requirements are not represented within the same context. [0019] Another problem with coded prototype based developments arises from the tendency for difficult problems to be pushed to the future, and not solved by the time of product completion, so that the initial hope of the prototype is not met by the subsequent product. [0020] Because of these limitations, another prototyping approach, referred to as static prototyping, has evolved. In this approach, only an image of the user interface of the prospective computer application is developed. This image may be created using commonly available drawing and diagramming software, and may be created without some of the drawbacks associated with employing programming resources to create a coded prototype. Prototypes created in this manner, however, suffer from additional drawbacks. Foremost among them is that such static prototypes created with drawing and diagramming software are unable to convey to stakeholders an understanding of or how the application will behave. Prototypes constructed in this manner do not exhibit many of the interactive behaviors of computer applications, e.g., navigation from screen display to other screen display, computation, storage and retrieval of data. They are therefore referred to as "static image prototypes" herein. It is commonly known in the field of the current invention, that stakeholders are much more apt to identify potential errors or omissions in the early phases of software development if they are permitted to interact with a prototype that does exhibit these interactive behaviors. [0021] To summarize the forgoing discussion of background art; coded prototypes suffer from drawbacks derived from the need to utilize computer programmers in their construction and static image prototypes suffer from drawbacks derived from the fact that they are inherently not interactive. Continue reading about Systems and methods for defining a simulated interactive web page... Full patent description for Systems and methods for defining a simulated interactive web page Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Systems and methods for defining a simulated interactive web page patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Systems and methods for defining a simulated interactive web page or other areas of interest. ### Previous Patent Application: System and method for designing and generating database-driven user interfaces that contain cascading plastic layout elements Next Patent Application: Utility network engineering and design rules in three-dimensional models of utility networks Industry Class: Data processing: software development, installation, and management ### FreshPatents.com Support Thank you for viewing the Systems and methods for defining a simulated interactive web page patent info. IP-related news and info Results in 0.16851 seconds Other interesting Feshpatents.com categories: Software: Finance , AI , Databases , Development , Document , Navigation , Error 174 |
 * Protect your Inventions * US Patent Office filing 
PATENT INFO |
|
