106 results about "Software build" patented technology

A system and method for improved testing of a software build is provided. The system and method automatically track differences between software builds by scanning the binaries of a software product to automatically discover its classes. The system and method then build a detailed dictionary that captures static and dynamic information of that build, including class dependencies. A comparison may be made with another build, so that the present invention may automatically execute selective tests on any types, and their dependencies, that have had a structural or behavioral modification since the last build. Testers may load a set of constructors for any specific types to further increase coverage of types (or classes) tested. The present invention may also provide detailed reports that may be used to drive future testing work and target specific areas of the code for additional testing. The system and method may further provide code generation from intermediate code to specified targets to aid in reproducing and fixing bugs.

A build optimization tool analyzes builds of software / firmware to determine the ordering of code objects in first and second code versions for an electronic client device such as a cellular phone, personal digital assistant, or pager. The build optimization tool produces information for use by a software linker to link the code objects of the second code version in a more optimal order for the production of updating information used in the electronic client device for updating the software / firmware of the electronic client device.

A framework for use with object-oriented programming systems provides a software build system that detects modules that make up a software product, examines each module to determine if it is up-to-date, and automatically updates any modules that require processing. The framework includes a software object of a class called "Product" that comprises a software product to be processed and built. An instance of the Product is comprised of multiple software build objects, each of which is called "Object". Each Object in turn contains four objects that are a kind of object class called BldSrc (Build Source). The BldSrc objects specify a different aspect of the software product and desired processing. Each of the software build objects in a Product's Object list is examined to determine if all four of the BldSrc objects is current. If any one of the software build objects is not current, the Object is re-built. If all four objects are current, the re-building step is skipped. In this way, each of the software build Objects making up a Product is automatically examined and processed, and the Product is produced.

Described is a system and method in which software images including updates are provided as packages. The package is self-describing, thereby facilitating the replacement of only component parts of an image. A software build process maps operating system features (comprising files, metadata, configuration information and so forth) into the packages, and executable code is processed for relocation purposes. The final package includes a device manifest file that describes the package and conveys dependency information and information about the priority of settings (shadow data).

A build optimization tool analyzes builds of software / firmware to determine the ordering of code objects in first and second code versions for an electronic client device such as a cellular phone, personal digital assistant, or pager. The build optimization tool produces information for use by a software linker to link the code objects of the second code version in a more optimal order for the production of updating information used in the electronic client device for updating the software / firmware of the electronic client device.

A system for managing software builds is provided. The system comprises a code control system operable to maintain a code version and a information associated with the code version, a parser module in communication with the code control system, the parser module operable to parse the information associated with the code version and create a change report, and a compiler module in communication with the code control system and operable to compile the code version into an object version based on the change report. A method of managing software builds is also provided. A method for building a software version is also provided.

A time and motion study is conducted to gather timings and factors for each portion of customer visits in an organization. This study draws data from existing management systems as well as special-purpose software built to collect additional data not available in current systems. Multiple regression is then used to analyze these data and determine which factors predict visit lengths, and to develop a model for predicting appointment lengths. This model is then used to assign appointments to different groups with different average lengths. These groups are then arranged in schedule templates and simulated using Monte Carlo simulation techniques. A schedule template is developed, tested and refined by repeated simulation. Finally, once a schedule template has been finalized, it is used to guide the scheduling of appointments, using a program which assigns appointments to one of the groups named by the schedule template, based on factors available at scheduling time.

A computerized system for preventing host intrusions on a communication device. The device is wirelessly connected to a wireless communication network. The system includes a computer readable management software module configured to analyze malicious payloads. The management software module includes an asset manager module configured to assign updates to the communication device, a device database module configured to describe the communication device characteristics and a build database module configured to automate software builds of the communication device core operating system. The management software module also includes a component builder module configured to run a plurality of instruction sets to establish a build environment for the communication device according to the communication device characteristics, a configuration manager module configured to build the instruction sets and an operating system product module configured by the build database module as part of a build process triggered by the asset manager module.

In response to detecting a software build break during testing, a change to a particular file committed to the software build that caused the software build to break is identified. A record of the change to the particular file is added to a sensitivity database, the sensitivity database accumulating multiple records of changes to the files of the software build during development of the software build. A relative level of failure of the particular file from the files of the software build based on the record in comparison with the multiple records is calculated. A sensitivity rating of the particular file to cause breaks in the software build based on the relative level of failure of the particular file weighted by one or more factors is generated. The sensitivity rating is output to one or more integrated development environment interfaces with access to the particular file of the software build.

A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Methods and systems for optimizing a build order of component source modules comprises creating a dependency graph based on dependency information. Historical build information associated with previous build failures is then used to calculate relative failure factors for paths of the dependency graph; and the relative failure factors are used to determine an order of traversal of the dependency graph during a build process in which component binary modules are built from the component source modules.

A LED Light device for house or stores or business application having built-in camera unit is powered by AC or-and DC power source for a lamp-holder, LED bulb, security light, flashlight, car torch light, garden, entrance door light or other indoor or outdoor LED light device connected to power source by (1) prongs or (2) male-base has conductive piece can be inserted into a female receiving-piece which connect with power source or (3) wired or AC-plug wires. The device has built-in camera-system has plurality functions to make different products and functions. The LED light device has at least one of (a) camera or DV (digital video) to take minimum MP4 or 4K image or photos, (b) digital data memory kits or cloud storage station, (c) wireless connection kits, Bluetooth or USB set for download function, (d) MCU or CPU or IC with circuit with desired motion sensor / moving detector(s) / other sensor, (e) camera-assembly for connecting Wi-Fi, Wi-Fi extend, or-and 3G / 4G / 5G network or even settle-lite channel, (f) system to transmit or-and receiving wireless signal, (g) APP or other platform incorporated with pre-programed or even AI (artificial intelligence) software has optional area-selections function to make screen-comparison or image comparison to operation pre-program or related device including but not limited to detect moving object(s), face recognition or personal identification or-and habit or-and crime comparison, purchase, (h) LED light source to offer sufficient brightness under dark environment for camera-assembly take color data, (i) other electric or mechanical parts & accessories, (j) has moving detector and software built-in to make comparison to judge the movement object of the preferred screen selected-areas; to get desired function(s) for the said LED light device. The said motion sensor / moving detector or other sensor unit has desired camera and Wi-Fi system and part or all of digital data related module or circuit(s) or backup power, and (k) camera-assembly may in separated housing incorporated with all kind of existing light source so people can upgrade the non-camera device to has built-in camera and digital device for their old non-camera security light.

A system for testing a software build is presented. A current software build is compared to a reference software build, typically a known, previous build. The comparison identifies those areas in the current software build that have changed with regard to the reference software build. The identified areas are used by a coverage analysis process to determine a focused test suite to test the modified areas of the current build. The test coverage analysis uses information in a master test suite to determine the focused test suite. The focused test suite is used by a test process to test the modified areas of the current software build. The coverage analysis process may also identify those areas of the current software build that cannot be tested using the tests in the master test suite. A report is generated identifying those areas that are not covered by the focused test suite.

A system and method for tracking and notifying related software, modules, and configuration files during software development and maintenance. A database, software build programming, a software module tracker, requirements management tools, and software source code that includes a comments area are implemented in connection with user interfacing to provide the method.

Automated testing of software builds having updated signature required modules, such as plug and play devices, is facilitated. A build (e.g., a daily build) of the software is performed, which includes one or more updated signature required modules. These modules are included within the build, even though the modules are unsigned. Automated testing is then performed against the daily builds.

A method of constructing a software build using a static structural analysis system is disclosed. A software build configuration may be run and analyzed by a software analyzer to detect dependencies among code classes and components. A code dependency map is constructed identifying code level dependencies. The code dependency map may be referenced for code classes and components selected for modification. Identified dependency relationships with the selected code classes and components enable a builder to rebuild those code classes and components affected by the modification. Additionally, the software analyzer may identify undesirable dependencies and anti-patterns in potential need of deletion or modification.

Testing of a software build. Differences between software builds are tracked by scanning the binaries of a software product to automatically discover its classes. A detailed dictionary is built that captures static and dynamic information of that build, including class dependencies. A comparison may be made with another build, so that selective tests may be automatically executed on any types, and their dependencies, that have had a structural or behavioral modification since the last build. Testers may load a set of constructors for any specific types to further increase coverage of types (or classes) tested. Detailed reports may also be provided that may be used to drive future testing work and target specific areas of the code for additional testing. Code generation from intermediate code to specified targets may also be performed to aid in reproducing and fixing bugs.

Systems and methods for generating a plurality of different software builds from a common base code and different combinations of other components are described in the context of a collaborative framework in which multiple parties maintain a shareable base of software used for generating such builds. Systems and methods for generating a plurality of different hardware build designs from a common collection of hardware elements and different combinations of other hardware components are also described.

In one embodiment of this invention, a computer system performs a method for validating a software build before check-in. A computer system accesses an existing software build of a software application that includes one or more existing binary files. The computer system accesses one or more updated binary files from a computer user. The computer system overwrites appropriate existing binary files in the existing software build with corresponding updated binary files for the updated binary files package. The overwriting included incorporating the updated binary files into the existing build of the software application without having to generate a new build of the software application. The computer system evaluates the functionality of the updated existing software build, wherein evaluating includes determining whether at least the updated binary files satisfy a threshold level of functionality. The computer system generates a report representing the results of the functionality evaluation.

A system and method for deploying a software build from a plurality of software builds is presented. A target computer sends a request for the software build to a build master. The build master authenticates the request, permitting only authorized requests. If the request is authorized, the build master identifies a build server that stores the requested software build. The build master generates request data that identifies the build server and authentication information, and returns the request data to the target computer. The target computer submits the request, with the request data, to the build server. The build server authenticates the request according to the request data. If the request is an authorized request, the build server returns the software build to the target computer.

A system and method for instrumenting a software build to automatically generate code coverage data without the use of external code coverage tools is presented. A software build is generated. The software build is independently executable. The software build is then instrumented to automatically generate code coverage data when executed. The instrumented software is executable independent of any external code coverage tools.

The invention provides a memory fault injection method and a simulator thereof for a software BIT. A hardware circuit board carrying out BIT software serves as a mock object of the simulator. An analog module for simulating normal functions of a memory, a fault modeling and model analysis module for establishing and analyzing fault sequence files, a fault injection module for matching the faults to be injected, and a fault behavior analog module and a peripheral cross-linking environment simulation module are added to the simulator. The method includes establishing a fault mode base, writing and analyzing extensive makeup language (XML) fault sequence files into identifiable fault sequences, searching and injecting corresponding faults when a processor accesses the memory, and performing fault simulation when the faults are triggered. According to the method and the simulator, the injected fault modes are complete and fully cover test cases under each fault occurrence for the memory, sufficient tests can be performed on the BIT software on a circuit board level, and only the BIT software after the sufficient tests can guarantee accuracy and timeliness of BIT fault prediction of aeronautical airborne equipment and further guarantee system reliability and safety.

A method for identifying predefined error conditions in a build output log file to determine if software build is defective. An output log file is generated within a storage device of a data processing system during a build of a software algorithm on the data processing system. A user creates a list file on the data processing system containing predefined valid error conditions. The output log file is searched to identify user-defined strings from the list file. A comparison of the user-defined strings identified during the search is made with predefined valid error conditions to determine when the user-defined strings identified matches the predefined valid conditions.

Described is a system and method in which software images including updates are provided as packages. The package is self-describing, thereby facilitating the replacement of only component parts of an image. A software build process maps operating system features (comprising files, metadata, configuration information and so forth) into the packages, and executable code is processed for relocation purposes. The final package includes a device manifest file that describes the package and conveys dependency information and information about the priority of settings (shadow data).

In one embodiment, a computer system packages a first set of data objects into a first software build. The computer system evaluates at least a portion of the usage of the first software build in accordance with usage training scenarios. The computer system monitors the evaluation of the first software build in accordance with a first software build usage detection process to detect the use of data objects within the first software build. The computer system generates profile data for the data objects and the generated profile data includes an indication of usage for each data object. The computer system packages a second set of data objects into a second software build in accordance with the generated profile data from the first software build, wherein the second set of data objects is different from but includes one or more data objects from the first set of data objects.

An interrelated set of tools and methods are disclosed for recording the identity of software components responsible for creating files, recording the identity of software components that access software files, reasoning about the dependency relationships between software components, identifying and reporting undesirable dependencies between them, and reporting other useful information about a large-scale software architecture by instrumenting a software build process or test process.

In one embodiment, a build orchestration framework orchestrates building of one or more individual buildable components of a deliverable software product. At least some buildable components reference respective sub components on which they depend. Building creates a structure associated with each respective buildable component of the one or more buildable components. In this structure, if the respective buildable component references a sub component on which the respective buildable component depends, a symbolic link is created to an output of a build of the sub component to provide access to the output of the sub component for use in building the respective buildable component. Further, in this structure, if the respective buildable component is used by another buildable component, a symbolic link is created to an output of a build of the respective buildable component.