Defect And Source Change Tracker for easy Regression
Disclosed is a software product feature that is unique
from others in that specific lines of code are linked with a software defect
report. Previous disclosures identify files changed to fix a reported defect,
but not specific lines of code. Subsequent changes to specific code alerts
defect author that regression testing of that code may be required. Defect And
Source Change Tracker (DASCT) can be used to implement tight integration
between defects and the code changed to resolve them. Using DASCT, when a
developer starts fixing a defect, there is a link created between the defect
and the lines of source code that changed. Thus it is indirectly creating a
relation between the source code controller and bug tracker for the lines of
code changed for each defect. When a developer modifies source used to fix
another defect, this integration will warn them about breaking the defect
already fixed. The responsible quality engineer can also be notified that code
has been modified and that they might need to revalidate one or more related
defects. There is also a link between the source code and the defect, so if the
defect reappears in the future; it is easy for the developer the see the code
he changed to fix this defect.
To implement Defect And Source
Change Tracker (DASCT), it is necessary to establish a link/bridge between the
source code control (change management) solution and defect-tracking tool. When
the developer fixes a defect, they need to reference what source code that is
changing in source code control. Once the source code is changed, using DASCT,
the defect tracker will store the lines changed to fix this defect. The next
time a developer touches the same code, DASCT will warn that the same code
resolves another defect. Developers can still do the changes, (some cases it
may be necessary), but the quality engineer responsible for the defect will be
notified of the source code modification. The quality engineer can validate the
defect again and can decide to keep the latest source code for future reference
if the defect is not broken. Even if a developer changes the same code, it does
not mean the previous defect will be broken. So, when both the developer and QE
agree the new fix does not affect the current defect fix, the new code will
used to compare future changes.
The quality engineer will no longer
need to regress defects previously submitted until notified by DASCT about a
change, which saves time. For developers, if the quality engineer re-submits
the defect (this will happen only if developer did the fix ignoring DASCT), he
can easily figure out the lines changed. DASCT may be referencing multiple
defects with multiple lines of code if same source code changes are used to fix
multiple defects. In this case, all the defect submitters will receive
notification when the source code is changed. DASCT can be implemented between
any change management or source code control solution and any defect tracking
The following diagram explains how
DASCT keeps track of the source code changes mentioned above. Here, DASCT is
acting as a central engine, which can talk to both the defect tracker and source
code control software. DASCT can convey messages to both the defect tracker and
source code control for changes and capable of notifying users, both developers
and quality engineers, about the change
Automated Software Product Inventory Control
Described is a mechanism to manage software products
across environments via a set of common tools/structures. Software is a
composite of many different entities. These entities can exist across
environments associated with the development, delivery, and usage of the
software. The characteristics of software entities may themselves be
different. For example, a program in the development environment may be a
source part while a program in the production environment may be an external
object or load module. The owner of these entities is usually the same in
these environments. Software entities may also be part of a software
product which exists at some maintenance level. It becomes very important
to correlate software product control information for a product across these
environments such that development activities, maintenance activities, and
problem determination activities can be done with some order and control.
The problem today is that there is
no good mechanism to manage software products across environments via a set of
common tools/structures. For example, an IBM development tool provides a
mechanism for developing source parts for a product but the tool manages source
parts in a totally different manner than the way the production environment
handles its corresponding objects in the Licensed Program (LP) production
The objective of this disclosure is
to increase software
management process efficiencies by defining common processes and structures for
software. These common processes and structures allow information
obtained during LP Library Control System Setup to be used throughout the LP's
life cycle to manage the software.
Another objective of this
disclosure to define how LP packaging
information defined during the development cycle may be propagated to
environments in which software may exist. These environments consist of
o Development environment - This is the environment in which
software is developed. It contains the
source entities from
which LP objects are formed.
o Intermediate production environment - This is the environment in
which released software may exist prior to being installed.
o Production environment - This is the environment in which
software is installed within an operating
packaged as LPs provide some well defined set of
Product control information is
defined during the development
phase. This information provides a mechanism to:
1. Declare up-front the data needed to manage software in the
2. Manage the transition of software in the development
to the production environments
3. Insure the consistency and completeness of information across
The Figure illustrates:
1. The software environments
2. The transitional flows between the environments
3. The functions this disclosure claims for the development
Efficient Gathering of Computer Audit Data Before and During Attack
1. Meaningful, reliable audit/log traces useful for
forensic analysis in computer security are basically a necessity for any
security analysis, but can quickly get very large (e.g. in the order of
100Mb/hour, see ), adding a significant performance hit onto computer
systems. Therefore in practice only a low level of audit data is gathered,
which is not allowing a detailed forensic analysis in case of an intrusion
2. In case of a successful intrusion on a computer system,
the attacker can in most cases change audit/log traces, thereby making an
analysis of the intrusion very hard resp. destroying the evidence and
consequences and repercussions of an intrusion. Current solutions:
usually in security conscious organizations a compromise is
taken: a manageable size of log data (restricted in detail and number of
machines - see e.g. , ) is taken to a central server (to avoid tampering
of an attacker) and stored for a time, which allows for discovery of a
intrusion (attempt) and analysis of the logs, before removal of the log data.
alternatively, cryptographic methods are used to make available
logs tamper resistant and destroying of log data at least detectable 
This compromise is unsatisfactory
from an intrusion detection standpoint for security & forensic analysis,
therefore an additional solution is proposed here. In normal operation, the
monitored computing systems (1) keep extensive audit logs locally (2) or
remotely by sending log data to a central logging server (3), but to keep log
files manageable, data is only kept for a very limited time, say x minutes
(where x is in the order of about 10 minutes, which should correspond to the
worst case reaction time of the deployed intrusion detection system (4)). If an
attack against the monitored computing system (1) is detected by some intrusion
detection sensor (4), the extensive audit trail from x minutes before the
attack is immediately fetched via a secure connection either from the monitored
computing system itself in case of local logging (5), or from the central log
server in case of remote logging (6).
Additionally (and optionally) the
intrusion detection sensor (4) can change the logging behavior on the attacked,
and now suspicious, computing system (7), e.g. to switch to 2 an even more
detailed level of logging, or remote instead of local logging. A possible
embodiment could be done with open-source tools: Secure Auditing for
Linux  can be used as source of a detailed audit trail, in their
architecture using a central remote collection point for the logs
Snort  can be used as intrusion detection sensor (4). Snort can be
customized to react with arbitrary scripts to intrusion alarms (by extension of
the 'react' method of the 'flexibly response' module). ssh  can
provide a secure channel to gather the log data in (5)/(6).
System for Upgrading Software and Related Data Files On a Need Basis Without Querying a
Problem or Opportunity
Applications and data files that are frequently run or
accessed need to be as up-to-date as possible to ensure the most efficient
system processing. The process for such an upgrade must be fast, accurate, and
most of all, secure.
Currently, the process for updating an application is
based on two factors: periodicity and an online database search. For instance,
the user computer is set to query an online database whenever a certain period
of time elapses: daily, weekly, or monthly. The database is available at a
specific website that the applicationÕs vendor maintains. The process searches
and queries the database for an entry indicating that a newer version of the
application is available. If an upgrade is found, the user computer is notified.
When the notification is accepted (with the simple click of a ÔYesÕ button, and
unsecured process), the upgrade is downloaded and installed on the user
Sometimes, this upgrade process can be set to occur when
the user computer starts up or shuts down. More often, however, this upgrade
process happens in real time during the work day while the user computer is
processing and, as a result, can interrupt work flow.
The process for updating a data file is manual. The user
computer must directly access a vendorÕs website and manually search the online
database for new versions of specific data files. This process is labor
intensive. It is also happenstance: the user must remember to regularly search
for available updates. Oftentimes, the user finds that no such update is
available and, as a result, wastes time and effort.
Both these processes—upgrading applications and
updating data files—also depend on the integrity of the queried database.
The database must accurately represent that upgrades and updates are available.
Detailed Description of Invention:
Applications must be upgraded and data files updated
seamlessly, regularly, quickly, accurately, and securely. This invention
accomplishes all these objectives.
As shown at a high level in Figure 1, the user computer
checks for application upgrades and data file updates based on a specific
number of uses (then a period of time as a backup position), directly searches
for a newer executable or data file (rather than querying a database), and downloads
and securely installs the new file when it is most efficient for the user
computer and user.
Figure 2 depicts a detailed flowchart of the method involved in
upgrading applications/updating data files (collectively referred to as
upgrading for the sake of simplicity).
Method starts with step 1, where the user computer
establishes the following settings:
number of times an application must run or a data file must be accessed, after
which a search for a newer version is undertaken. For example, if the usage
number is set to 5, then the user computer searches for a newer file after the
application has run 5 times or after the data file has been accessed 5 times.
¬ An amount
of time that must elapse, after which a search for a newer version is
undertaken. This is a threshold setting. It is set so that the user computer
can ensure that an application or data file is updated after a specific amount
of time regardless of the number of times it has run. For example, the user
computer searches for newer files after every 5 uses or every day, whichever is
sooner. This setting is particularly useful for applications or data files that
are rarely run or accessed.
¬ When the
user computer should search for a newer file: at startup, at shutdown, at a
specific time of day, or after the usage number has been attained. This setting
enables the user computer to determine when a search for a newer file actually
happens. The user has some control over system performance, when new files are
installed, and how often.
Using these settings, the user computer determines when to
search for a new file.
In step 2, the applications are running on user computer
and data files are accessed as part of normal operation of user computer.
In decision step 3, the user computer periodically checks
to see if the criteria established in step 1 are met. If so, the method
proceeds to step 4. If not, the method returns to step 2.
In step 4, user computer searches for a newer file,
accessed from a cloud of online resource files where
available as a service. The user computer attempts to locate the actual file
rather than querying a database (since maintaining a database first requires
the newer file be available and then, second, requires that the database be
In decision step 5, user computer determines if the new file
is newer by comparing to the versions currently available on the user
computerÕs resident hard drive. The comparison can be based on the file name,
the fileÕs date and time, or any other method that uniquely identifies a newer
file. If so, the method proceeds to step 6. If not, the method returns to step
In step 6, when a newer file is found, the user computer
automatically downloads it in the background when system processing on the user
computer is low so as not to adversely affect processing.
In step 7, after the file has successfully downloaded, the
user computer notifies the user that an upgrade or update is available, lists
the details of the downloaded file, and specifies if a restart is required
following installation. (In general, installing executable files require a
restart whereas installing data files does not.) This notification happens in
accordance with the specified search-time criteria (described in the third
bullet above), so the user is interrupted only when requested.
In decision step 8, the user or user computer makes a
determination whether or not to install the update. If so, the method proceeds
to step 9. If not, the method returns to step 2.
In step 9, to ensure the security of the user computer and
that of the downloaded file, the user reviews the details of this file to
ensure its accuracy and legitimacy and may enter a password to initiate the
installation (rather than simply clicking a ÔYesÕ button). After installing the
upgrade or update, the user computer automatically restarts (if required) or
immediately returns processing to the user. Method ends.
Method for Uninstalling an Unwanted Application Upgrade
Problem or Opportunity
the vast majority of applications is simple. At varying times, the application
polls the appropriate web sites searching for an upgrade to the version
currently running on the user computer. When one is found, the upgrade program
notifies the user. In general, the user can then choose to upgrade immediately
or put off the upgrade for a brief period of time (such as a day). Eventually,
the user chooses to install the upgrade.
Sometimes, however, after an upgrade is installed, the
user simply does not want it. This can happen for any number of reasons. The
that the upgrade is incompatible with the operating system currently running on
the user computer.
that the upgrade fixes an incompatibility with another application which was
not installed or even owned.
¬ Sees that
the upgrade contains unwanted (oftentimes, even annoying) features.
does not want the upgrade.
When this occurs, the user has only one alternative: to
reinstall the application from its initial version and then install whatever
upgrades were available to bring the application back to the version that was
running just before the most recent—and unwanted—upgrade was
installed. In other words, the user must reinstall the application from the
This invention allows the user to uninstall the most recent
upgrade, a much quicker and more reliable process. In other words, arrive at
the applicationÕs previous version from the top down.
Detailed Description of the Invention
Figure 1 shows the flowchart depicting the method for
uninstalling an application upgrade. Following the flowchart is a more detailed
explanation of each step
The method of uninstalling
an unwanted upgrade starts with step 1. In this step, the user computer
identifies an available upgrade, and notifies the user who then accepts the
In decision step 2, the user computer asks if the user
wants the ability to uninstall the upgrade. If yes, the method proceeds to step
3; if no, the method continues with step 5.
In step 3, the user computer creates an uninstall version
of the application to be upgraded. The user computer copies the current version
of the application and all its related files, and identifies the location of
each of these files. The user computer basically creates a snapshot of its
current structure in such a manner as to make uninstalling the upgrade simple,
seamless, and error free.
In step 4, the user computer asks the user to specify a
period of time to keep the uninstall version of the application being upgraded.
The user enters the number of minutes, hours, or days to keep the uninstall
version. This setting can be changed later as necessary by the user (see step
In step 5, the user computer upgrades the application as
required, requiring a password and restarting as necessary.
In decision step 6, after installing the upgrade, the user
computer identifies if an uninstall version has been created. If no, the method
proceed to the end and finishes; if yes, the method continues with step 7.
In decision step 7, after the specified period of time
(set in step 4) elapses, the user computer asks if the user wants to uninstall
the upgrade. If yes, the method continues to step 8; if no, the method proceeds
to step 9.
In step 8, the user computer reverts to the previous
version of the upgraded application by re-establishing the appropriate settings
as saved in step 3, then deleting the files related to the upgrade. The method
In decision step 9, the user has decided not to uninstall
the upgrade; in other words, to keep the upgraded version of the application.
The user computer asks if the user still wants the ability to uninstall the
upgrade at a later time. If yes, the method continues with step 10; if no, the
method proceeds to step 11.
In step 10, the user either confirms the period of time
specified in step 4 or sets a different period of time. The method returns to
In step 11, the user has decided to permanently keep the
upgraded version of the application. The user computer then deletes the
uninstall version created in step 3.
The method ends.