Providing a notification when a plurality of users are altering similar data in a health care solution environment

Abstract

A notification when multiple users attempt to alter the same data may first begin when connections to a plurality of user stations are monitored. An instruction for initiating a load process is received from a user station. Data is downloaded from the one of the user stations to the server. It is determined whether another load process is being concurrently executed by another user station. If it is determined that a load process is being concurrently executed, a notification is sent to the user station. A notification is also sent to the user station that initiated the concurrently executing load process. At least one of the load processes is suspended upon detecting the concurrently executed load process. At least one of the load processes may be allowed to continue upon receiving a command to continue from the user station associated with the suspended load process.

Claims

What is claimed is:

1. A method for providing a notification when multiple users attempt to alter the same data, comprising the steps of:

(a) monitoring connections to a plurality of user stations;

(b) receiving an instruction from a first user stations for initiating a first load process for loading data from said first user station to a server;

(c) downloading the data to be loaded from the first user station to the server in a first load process;

(d) after said downloading, determining whether a second load process is being concurrently executed by a second user station;

(e) sending a notification to the first user stations if it is determined that a second load process is being concurrently executed;

(f) sending a notification to the second user station;

(g) suspending at least one of the first or second load processes upon it being determined that the second load process is being concurrently executed; and

(h) allowing the suspended load processes to continue upon receiving a command to continue from user stations initiating the suspended load processes.

2. A method as recited in claim 1, wherein the data includes medical records.

3. A method as recited in claim 1, wherein the connections to the user stations are via a wide area network.

4. A method as recited in claim 1, wherein both of the load processes are suspended upon it being determined that the second load process is being concurrently executed.

5. A method as recited in claim 1, wherein only the second load process is suspended upon it being determined that the second load process is being concurrently executed.

6. A method as recited in claim 1, wherein the notification includes at least one of a pop-up window, an email, and a facsimile.

7. A computer program embodied on a computer readable medium for providing a notification when multiple users attempt to alter the same data, comprising:

(a) a code segment that monitors connections to a plurality of user stations;

(b) a code segment that receives an instruction from a first user station for initiating a first load process for loading data from said first user station to a server;

(c) a code segment that downloads the data to be loaded from the first user station to the server in a first load process;

(d) a code segment that determines after said downloading, whether a second load process is being concurrently executed by a second user station;

(e) a code segment that sends a notification to the first user station

(f) a code segment that sends a notification to the second user station;

(g) a code segment that suspends at least one of the first or second load processes upon it being determined that the second load process is being concurrently executed; and

(h) a code segment that allows the suspended load processes to continue upon receiving a command to continue from user stations initiating the suspended load processes.

8. A computer program as recited in claim 7, wherein the data includes medical records.

9. A computer program as recited in claim 7, wherein the connections to the user stations are via a wide area network.

10. A computer program as recited in claim 7, wherein both of the load processes are suspended upon it being determined that the second load process is being concurrently executed.

11. A computer program as recited in claim 7, wherein only the second load process is suspended upon it being determined that the second load process is being concurrently executed.

12. A computer program as recited in claim 7, wherein the notification includes at least one of a pop-up window, an email, and a facsimile.

13. A system for providing a notification when multiple users attempt to alter the same data, comprising:

(a) logic that monitors connections to a plurality of user stations;

(b) logic that receives an instruction from a first user stations for initiating a first load process for loading data from said first user station to a server;

(c) logic that downloads the data to be loaded from the first user stations to the server in a first load process;

(d) logic that determines after said downloading, whether a second load process is being concurrently executed by a second user station;

(e) logic that sends a notification to the first user stations if it is determined that a second load process is being concurrently executed;

(f) logic that sends a notification to the second user station;

(g) logic that suspends at least one of the first or second load processes upon it being determined that the second load process is being concurrently executed; and

(h) logic that allows the suspended load processes to continue upon receiving a command to continue from user stations initiating the suspended load processes.

14. A system as recited in claim 13, wherein the data includes medical records.

15. A system as recited in claim 13, wherein the connections to the user stations are via a wide area network.

16. A system as recited in claim 13, wherein both of the load processes are suspended upon it being determined that the second load process is being concurrently executed.

17. A system as recited in claim 13, wherein only the second load process is suspended upon it being determined that the second load process is being concurrently executed.

18. A system as recited in claim 13, wherein the notification includes at least one of a pop-up window, an email, and a facsimile.

Description

FIELD OF THE INVENTION

The present invention relates to system management and more particularly to a data safeguarding mechanism.

BACKGROUND

Computerized databases are commonly used to store large amounts of data for easy access and manipulation by multiple users. In a centralized computer system, there is a single copy of the data stored at one location, typically a computer. By maintaining a single, centralized database, such a system avoids inconsistencies which might otherwise occur with more than one copy of the data. Nevertheless, the centralized database approach has several drawbacks. First, since only one copy of the data exists, if the data becomes corrupted or inaccessible, the entire system becomes unavailable. Second, with only one copy of data available for read and update purposes, the system may appear slow and time-consuming, especially to multiple users.

Consequently, many of today's organizations, especially those dispersed over several locations, utilize some type of distributed database system. In a distributed system, an organization's data is spread across the storage facilities of several computers or processors. These storage facilities may be located throughout a single building, across several adjacent buildings or at different locations across the country or around the world. These computers or processors are interconnected via a communications network and are referred to as sites or nodes. Each site, moreover, is able to process local transactions which access data retained only at that local storage facility as well as distributed transactions which access data stored on more than one computer.

Computerized databases, both centralized and distributed, are often used to execute transactions. A transaction is a set of data-dependent operations requested by a user of the system. For example, a user may request some combination of retrieval, update, deletion or insertion operations. The completion of a transaction is called a commitment and the cancellation of a transaction prior to its completion is referred to as an abort. If a transaction is aborted, then any partial results (i.e., updates from those operations that were performed prior to the abort decision) must be undone. This process of returning the data items to their original values is also referred to as a roll back. An important aspect of a transaction is atomicity. Atomicity means that all of the operations associated with a particular transaction must be performed or none of them can be performed. That is, if a transaction is interrupted by a failure, the transaction must be aborted so that its partial results are undone (i.e., rolled back) and, if the transaction is completed, the results are preserved (i.e., committed) despite subsequent failures. The classic example of atomicity concerns a transfer of bank funds from account A to account B. Clearly, the system must either perform both the withdrawal and the deposit operations of the transaction or neither operation.

To protect against disruptions caused by the failure of any particular site, most distributed database systems allow additional copies or "replicas" of the data to be made at other sites. That is, a copy of each data item stored on one of the system's database facilities may also exist at the database facilities of other sites. By replicating the data across multiple instances of database facilities, a certain degree of fault-tolerance may be obtained. Furthermore, by having a locally available replica of the database available, the response time of certain transactions may be improved.

Although replicated systems provide the above advantages over non-replicated systems, there are nonetheless inherent costs associated with the replication of databases. To update a single data item, at least one message must be propagated to every replica of that data item, consuming substantial communications resources. Furthermore, in order to manage multiple databases and handle the execution of concurrent transactions, a complicated administrative support mechanism is required. In addition, if the replicated system cannot guarantee consistent updates at all replicas, data integrity may be compromised.

Most commercially available replicated database systems utilize either a distributed transaction approach or a primary-backup approach to replicate the data. In the distributed transaction approach, all database replicas are updated with a single, distributed transaction. That is, whenever a data item is updated by a transaction, all copies or replicas of that data item are updated as part of the same transaction. This approach results in completely synchronized replicas. To ensure atomicity, distributed transaction-based systems must employ an atomic commit protocol, such as the well-known 2 Phase Commit ("2PC") protocol. The basic idea behind 2PC is to determine a unique decision for all replicas with respect to either committing or aborting a transaction and then executing that decision at all replicas. If a single replica is unable to commit, then the transaction must be aborted at all replicas.

More specifically, under the 2PC protocol, a single database manager associated with a single database facility is chosen as the coordinator of the transaction. The coordinator first asks all of the participants (i.e., the other replicas) including itself (if the coordinator is a participant) to prepare for the commitment of a transaction. Each participant replies to the coordinator with either a READY message, signaling that the participant is ready and willing to commit the transaction, or an ABORT message, signaling that the participant is unable to commit the transaction. Before sending the first prepare message, the coordinator typically enters a record in a log stored on stable storage, identifying all of the replicas participating in the transaction. The coordinator also activates a time-out mechanism. Based on the replies received from the participants, the coordinator decides whether to commit or abort the transaction. If all participants answer READY, the coordinator decides to commit the transaction. Otherwise, if at least one participant replies with an ABORT message or has not yet answered when the time-out expires, the coordinator decides to abort the transaction.

The coordinator begins the second phase of 2PC by recording its decision (i.e., commit or abort) in the log. The coordinator then informs all of the participants, including itself, of its decision by sending them a command message, i.e., COMMIT or ABORT. In response, all of the participants write a commit or abort record in their own logs. Finally, all participants send a final acknowledgment message to the coordinator and execute the relevant procedures for either committing or aborting the transaction. The acknowledgment message, moreover, is not simply an acknowledgment that a command has been received, but is a message informing the coordinator that the command has been recorded by the participant in its stable log record. When the coordinator receives the acknowledgment messages from the participants, it enters a "complete" record in its log.

Although widely implemented, the 2PC protocol nonetheless has several disadvantages. First, as set forth above, the protocol requires each replicated database facility to submit a READY message before the transaction can be committed. Thus, in a fully replicated environment, any site or link failure brings all activity to a complete halt until the site or link is repaired, since that site cannot transmit a READY message. That is, until the failed site is recovered, no further transactions may be executed by a system relying on 2PC. Second, 2PC requires the transmission of at least three messages per replicated database per transaction. The protocol thus consumes substantial communications resources and reduces the system's response time and throughput. Third, 2PC requires both the coordinator and all participants to record the commit/abort decision and the final outcome to stable storage. This involves two forced disk writes per participant per transaction, adding significant overhead to this protocol. Other protocols, such as Quorum Consensus, have been proposed as a solution to the first problem, but these other protocols impose even more communications overhead than 2PC and, as a result, they have not been utilized in commercial systems.

In the primary-backup approach, all transactions update a single, specific replica site, referred to as the primary site. These updates are later copied to the other replicas in the system, which are referred to as backup replica sites. The precise manner in which the updates are propagated to the backup sites varies from implementation to implementation. For example, some systems update the backup replica sites as soon as possible, typically resulting in minimal delays of several seconds. Others update the backup sites at specific time intervals or after a specific number of transactions have committed at the primary site. Some systems, moreover, perform the backup function by transferring entire recovery logs in order to perform the transactions at the other backup sites. Still others create a deferred log of transaction requests which are later used to do the updates. Commercial products incorporating the primary-backup approach to replication include Sybase Replication Server, the Oracle Snapshot Facility, Oracle Symmetric Replication, Oracle Standby Database, Ingres/Replicator and DB2 Data Propagator.

One of the apparent advantages of the primary-backup approach is the ability to create a highly available database system by replacing a failed primary with one of the backups, allowing he backup to become the new primary. This approach, however, has several drawbacks. First, update propagation to the backups typically generates a large amount of network traffic, consuming significant network resources. Second, regardless of the precise manner by which updates are propagated, the backups will always lag the primary. Transactions, moreover, are typically executed serially at the backup sites to avoid data inconsistencies resulting from possibly different execution orders at the primary and backup sites. Hence, in high volume applications, backup sites can lag the primary by tens if not hundreds of transactions. This has serious data consistency consequences both during normal processing and, in particular, after failures.

During normal processing, applications typically access the backups for read-only purposes to improve processing capabilities. Nonetheless, as mentioned above, data at the backup sites may be stale, causing potential problems depending on application requirements. Furthermore, after a primary site failure, both database and real world inconsistencies are likely to arise due to update decisions at the new primary based on stale data. For example, if the sale of the last widget in stock was recorded at the primary site but not propagated to any of the backup sites by the time of a primary failure, then the last widget may be sold a second time by a transaction executing at the new primary.

In addition to being prone to data inconsistencies, the primary-backup approach does not automatically allow for transparent failover to a backup site after a primary failure. First, after a primary failure, application clients must be switched over to a new primary. This process involves significant time during which the system is unavailable. Second, since the backup sites are not always consistent with each other, difficulties arise choosing a new primary from the various backups. Moreover, failures that result in network partitions may result in more than one backup declaring itself the new primary.

In addition to the distributed transaction and primary-backup approaches to database replication, at least one attempt has been made to utilize state machines as a basis for replicating data at different sites. This system, however, requires all transactions to be executed serially at all replicas and thus does not support the concurrent execution of transactions. Basically, a state machine is a entity containing a set of states and a set of commands which transform those states such that all of the new states are also contained within the machine. The prior state of the art of the state machine approach to replication management is described in F. Schneider Implementing Fault-tolerant Services using the State-Machine Approach: A Tutorial ACM Computing Surveys 22 (December 1990). The basic idea of the state machine approach is to start with some number of state machines, and arrange for commands to be sent to all state machines where they may concurrently and independently execute. In order to achieve consistent data replication, however, the commands must be deterministic. That is, the commands must produce identical results when operating on identical states. The requirement that commands be deterministic presents a significant problem in applying this approach to database systems (or, more generally, to transaction-based systems).

SUMMARY OF THE INVENTION

A notification when multiple users attempt to alter the same data may first begin when connections to a plurality of user stations are monitored. An instruction for initiating a load process is received from one of the user stations. Data is downloaded from the one of the user stations to the server. It is determined whether another load process is being concurrently executed by another user station. If it is determined that a load process is being concurrently executed, a notification is sent to the one of the user stations. A notification is also sent to the user station that initiated the concurrently executing load process. Both users are notified to allow them to coordinate their updates so that all alterations to the data are entered. At least one of the load processes is suspended upon detecting the second concurrently executed load process to allow the users time to react to the notification upon it being determined that another load process is being concurrently executed. One of the load processes, all but the first load process, all of the load processes, or any other combination can be suspended. At least one of the load processes may be allowed to continue upon receiving a command to continue from the user station associated with the suspended at least one of the load processes.

In one aspect of the present invention, the data includes medical records. As an option, the connections to the user stations are via a wide area network. Also optionally, the notification can be one or more of a pop-up window, an email, and/or a facsimile.

BRIEF DESCRIPTION OF DRAWINGS

The invention will be better understood when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:

FIG. 1 is a schematic diagram of a hardware implementation of one embodiment of the present invention;

FIG. 2 illustrates a data load process in which a single user runs the process on an individual client desktop (user station);

FIG. 3 is a flowchart depicting a process for providing a multi-tier client/server architecture for storing files and/or records;

FIG. 4 is a flowchart illustrating a process for providing a notification when multiple users attempt to alter the same data;

FIG. 5 depicts a process for providing status messaging during data loading in a multi-tier client/server architecture;

FIG. 6 is a flowchart that illustrates a process for generating error and summary reports for a data load;

FIG. 7 is a flowchart illustrating a process for loading data in a multi-tier client/server architecture;

FIG. 8 is an illustration of the Integrated Development Environment Architecture (IDEA);

FIG. 9 is an illustration showing a Development Organization Framework in accordance with one embodiment of the present invention;

FIG. 10 is an illustration showing a security organization functional according to one embodiment of the present invention;

FIG. 11 is an illustration showing the responsibilities of an Environmental Management Team;

FIG. 12 is an illustration showing the responsibilities of an Application Team structure;

FIG. 13 is an illustration showing a model migration plan in accordance with one embodiment of the present invention;

FIG. 14 is an illustration showing a single release capability development pipeline in accordance with one embodiment of the present invention;

FIG. 15 is an illustration showing a multiple release capability development pipeline in accordance with one embodiment of the present invention;

FIG. 16 is an illustration showing a multiple release capability development pipeline with code base synchronization among three pipelines;

FIG. 17 is an illustration showing a Development Tools Framework in accordance with one embodiment of the present invention;

FIG. 18 is an illustration showing information captured in the Repository and reused;

FIG. 19 is an illustration showing the Repository's central role in the development environment; and

FIG. 20 is an illustration showing an Operational Architecture Framework in accordance with one embodiment of the present invention.

DISCLOSURE OF THE INVENTION

A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in FIG. 1, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 110, such as a microprocessor, and a number of other units interconnected via a system bus 112. The workstation shown in FIG. 1 includes a Random Access Memory (RAM) 114, Read Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk storage units 120 to the bus 112, a user interface adapter 122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, and/or other user interface devices such as a touch screen (not shown) to the bus 112, communication adapter 134 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 136 for connecting the bus 112 to a display device 138. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided.

OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.

When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, our logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:

Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.

Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.

An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.

An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.

With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects.

This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.

Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

The benefits of object classes can be summarized, as follows:

Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems.

Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.

Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.

Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.

Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.

Libraries of reusable classes are useful in many situations, but they also have some limitations. For example:

Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes.

Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects.

Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.

Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.

There are three main differences between frameworks and class libraries:

Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.

Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.

Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language--2.0" (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, "Hypertext Transfer Protocol--HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

Poor performance;

Restricted user interface capabilities;

Can only produce static Web pages;

Lack of interoperability with existing applications and data; and

Inability to scale.

Sun Microsystem's Java language solves many of the client-side problems by:

Improving performance on the client side;

Enabling the creation of dynamic, real-time Web applications; and

Providing the ability to create a wide variety of user interface components.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.

Sun's.RTM. Java.RTM. language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution."

Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi.RTM., Microsoft Visual Basic.RTM. programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta.RTM.." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.

DATA LOAD PROCESS

An embodiment of the present invention is a data load process that automates the process of loading large volume configuration or conversion data into a database in a health care solution framework. The process can be used to automate the normally manual, time intensive process of loading data via a front-end user interface.

The load process can be used to allow a user to:

Create logical sets of data organized around "keywords"

Specify the keywords to be loaded via client GUI

Specify input Data Management Templates (DMT's), or tab or pipe (.vertline.) delimited ASCII text files to be loaded via a client GUI

Be notified if multiple users are attempting to alter the same data

Receive continuous status messages throughout the loading process

Review error reports and load summary reports

Maintain database integrity by eliminating insertion of erroneous data

The data load process provides the following benefits:

Minimizes configuration problems due to human error

Produces highly replicable and consistent results

Eliminates the insertion of erroneous data by enforcing business rules/requirements and ensuring that referential integrity, codependency, primary key, required field, default field, sequence number, and hard-coded field checks are met.

Minimizes the technical knowledge required on a configuration team in order to load data into the database

Ability for users with little technical knowledge to identify data errors in input files and re-run the load application

Can be used for initial loads of development or testing environments as well as for one-time conversions

In one embodiment of the present invention, the keywords are organized into a tier structure, where all keywords within one tier must be loaded before the next tier can be started.

FIG. 2 illustrates a data load process 200 in which a single user runs the process on an individual client desktop 202 (user station). An illustrative data load process may be embodied in a three tier client/server architecture including a Graphical User Interface (GUI) built in Microsoft Access, a server application built in C, Pro*C, Perl 5 and Unix korn shell scripts, Oracle SQL*Loader scripts, and a series of Oracle PL/SQL stored procedures.

In the data load process, a user logs onto the system. See arrow ref 208. As shown at arrow ref 210, the user selects specific keywords within a tier 204 to load into the database 206. The user executes a load process at arrow ref 212 and files to be loaded are transferred to the server at arrow ref 214. A load process control module is executed and the corresponding DMT(s) for the selected keyword(s) are sent to the server application. See arrow ref 216. A check for concurrently executing load processes is performed in operation 218. The success of the file transfer is performed in operation 220. In operations 222 and 224, the files are reformatted and loaded into tables by the server application loads data into worktables. The server application initiates stored PL/SQL procedures to perform validation. See operation 226. Data is validated according to database and/or client-specific business rules. If no validation errors are found, data is loaded into the Diamond database. See operation 228. If errors are found, a file containing all the good records, and a file containing all the bad records are sent back to the client desktop. See arrow ref 230. A report is produced listing all the erred records and the corresponding row numbers and error messages. Also, a verification report is produced that provides control totals for data loaded into database, or written to good/bad files. The reports can then be reviewed by the user. See arrow 232.

Optionally, in order for data to be loaded, all data on any one DMT must be completely correct. If the Load Application finds any data errors on a DMT, the correct and incorrect records will be written to separate files (i.e.--"good" file and "bad" file), and no data will be inserted into the tables.

FIG. 3 is a flowchart depicting a process 300 for providing a multi-tier client/server architecture for storing files and/or records such as medical records. In operation 302, a connection is maintained between multiple user stations and a server that has a database. In this and the other embodiments set forth herein, the connection may be maintained utilizing a local area network or a wide area network. Alternatively, a dialup connection could be created periodically or upon user request. A plurality of records/files and a command to load the records into the database are received from one of the user stations in operation 304. The command may be ordered by the user, or may be executed automatically. If the command is executed automatically, it may be performed at predetermined intervals. In operation 306, a data management template corresponding to the files/records is selected. The data management template may include a listing of all records/files that should be loaded. Alternatively, the data management template may specify particular content of the files/records that must be matched for verification. As another option, the data management template may specify specific particular sizes of the files/records. In operation 308, it is validated that all of the records/files to be loaded match the data management template. In operation 310, the records/files are sent to a database for loading in the database upon validation that the records match the data management template.

In one embodiment of the present invention, files/records that match the data management template are separated from files/records that do not match the data management template. Also, a list of records/files that match the data management template and records/files that do not match the data management template may be compiled and may be sent to the user station.

In another embodiment of the present invention, no records are sent to the database if any of the records do not match the data management template. This prevents entry of erroneous data. Optionally, records that match the data management template are separated from records that do not match the data management template. The records are then sent to the user station if there are records that do not match the data management template.

In yet another embodiment of the present invention, the records are medical records. As an option, a notification is sent to the user station upon detecting a concurrently executing load process.

FIG. 4 is a flowchart illustrating a process 400 for providing a notification when multiple users attempt to alter the same data. In operation 402, connections to a plurality of user stations are monitored. This may be done continuously or at predetermined intervals, for example. An instruction for initiating a load process is received from one of the user stations in operation 404. Data is downloaded from the one of the user stations in operation 406. In this and other embodiments of the present invention, the data may be in the form of files or records, for example. In operation 408, it is determined whether another load process is being concurrently executed. If it is determined that a load process is being concurrently executed, a notification is sent to the one of the user stations in operation 410. A notification is also sent to the user station that initiated the concurrently executing load process in operation 412. Such notifications may include a pop-up window, an email, and/or a facsimile, for example. Both users are notified to allow them to coordinate their updates so that all alterations to the data are entered.

With continuing reference to FIG. 4, at least one of the load processes is suspended in operation 414 upon detecting the concurrently executed load process to allow the users time to react to the notification. One of the load processes, all but the first load process, all of the load processes, or any other combination can be suspended upon it being determined that another load process is being concurrently executed. At least one of the load processes should be allowed to continue upon receiving a command to continue from the user station associated with the suspended at least one of the load processes. See operation 416.

In one embodiment of the present invention, the data includes medical records. As aforementioned, the connections to the user stations may be via a wide area or local area network.

FIG. 5 depicts a process 500 for providing status messaging during data loading in a multi-tier client/server architecture. In operation 502, data is downloaded from a user station. A status of the download of the data is transmitted to the user station in operation 504. Preferably, the status is displayed as it is received. In operation 506, the data is divided into divisible portions. Each of the divisible portions of the data is checked in operation 508 to validate that the data meets predetermined criteria, such as that it includes certain content. In operation 510, a message is sent to the user station indicating whether the divisible portions of the data meet the predetermined criteria. The data is loaded in a database in operation 512. The data may include medical records.

In one embodiment of the present invention, a list of data that matches the predetermined criteria and data that does not match the predetermined criteria is compiled. As an option, data that matches the predetermined criteria is separated from data that does not match the predetermined criteria. The separated data is transmitted to the user station. The data may be transmitted during separation or may be transmitted after separation.

Preferably, the divisible portions of the data are loaded into a table before validating that the data meets the predetermined criteria. Optionally, a notification may be sent to the user station upon detecting a concurrently executing load process.

FIG. 6 is a flowchart that illustrates a process 600 for generating error and summary reports for a data load. In operation 602, a plurality of records to be loaded in a database are received. The records may include medical records. A data management template corresponding to the records is chosen in operation 604. In operation 606, it is verified that all records to be loaded match the data management template. All or matching records are sent to a database in operation 608 for loading in the database upon validation that the records match the data management template. A report of records that match the data management template and records that do not match the data management template is compiled in operation 610.

In one embodiment of the present invention, records that match the data management template are separated from records that do not match the data management template. The separated records are sent to a user station if there are records that do not match the data management template.

In another embodiment of the present invention, no records are sent to the database if any of the records do not match the data management template. Preferably, the records are loaded into a table before validation of the records. As an option, a notification may be sent to a user station or log file upon detecting a concurrently executing load process.

FIG. 7 is a flowchart illustrating a process 700 for loading data in a multi-tier client/server architecture. In operation 702, a plurality of user-selected keywords are received. Data is organized around the keywords. The data can include medical-related data such as medical records. A data management template which corresponds to the keywords is selected in operation 704. A validation is performed in operation 706 to determine whether all of the data to be loaded matches the data management template. The data is sent to a database in operation 708 to be loaded in the database upon validation that the data matches the data management template.

In one embodiment of the present invention, data that matches the data management template is separated from data that does not match the data management template. A list of data that matches the data management template and data that does not match the data management template is compiled.

In one embodiment of the present invention, no data is sent to the database if any of the data does not match the data management template for eliminating insertion of erroneous data. In another embodiment of the present invention, the data is loaded into a table before validation of the data. Optionally, a notification is sent to a user upon detecting a concurrently executing load process.

The following discussion with respect to FIGS. 8-20 describes frameworks that may be used to implement the above-described embodiments of the present invention.

DEVELOPMENT FRAMEWORK (IDEA)

FIG. 8 is an illustration of the Integrated Development Environment Architecture (IDEA). The Integrated Development Environment Architecture provides a. development environment framework and associated guidelines that reduce the effort and costs involved with designing, implementing, and maintaining an integrated development environment. IDEA takes a holistic approach to the development environment by addressing all three Business Integration components: organization, processes, and tools.

The development environment is a production environment for one or several systems development projects as well as for maintenance efforts. It requires the same attention as a similarly sized end-user execution environment.

The purpose of the development environment is to support the tasks involved in the analysis, design, construction, and maintenance of business systems, as well as the associated management processes. The environment should adequately support all the development tasks, not just the code/compile/test/debug cycle. Given this, a comprehensive framework for understanding the requirements of the development environment should be used.

Another reason for the comprehensive framework is that it is important to get the development environment right the first time. Changing the development environment when construction is fully staffed entails serious disruptions and expensive loss of productivity.

Experience has shown that within the same medium- to large-size project, with the same people, moving from a poor to a good development environment, productivity is improved by a factor of ten for many tasks. The improvements come in two categories:

The elimination of redundant and non value-added tasks

The streamlining of useful tasks

While it seems intuitive that most tasks can be streamlined, the following list gives a few examples of redundant tasks that must be eliminated:

Analysis to determine how to merge the uncoordinated changes applied by two programmers to the same module

Re-entry of the source code and retesting of a module, which was accidentally deleted

Recurring discussions about "what a design packet should contain" or "what constitutes good programming style in a particular context"

Repeated design, coding, testing, and maintenance of very similar logic (for example, error handling, date conversion and manipulation, main structure of a module)

Searching for the manuals of a particular productivity tool to find information

Remigration to system test of a cycle, because the impact analysis for a change request was incomplete

Requesting support from another team (for example, environment support, information management) and waiting unnecessarily for a response

On a smaller project, these problems can be solved using a brute force approach. This becomes very expensive as the project grows, and finally impossible. A well-designed development environment becomes important as the project team reaches 20-30 people and is absolutely critical with a project size of more than 50 people.

The investment required to design, set up, and tune a comprehensive, good development and maintenance environment is typically several hundred development days. Numbers between 400 and 800 days are commonly seen, depending on the platforms, target environment complexity, amount of reuse, and size of the system being developed and maintained.

DEVELOPMENT ORGANIZATION FRAMEWORK

FIG. 9 is an illustration showing a Development Organization Framework in accordance with one embodiment of the present invention. When designing a business application, it is crucial to keep in mind the organization that will use the system. The same is true of the development environment. The development organization's size, structure, experience, and maturity should strongly influence the choice of tools and the way the tools are integrated. If this link is not understood, the benefit of tool support will be minimal in many areas, and may significantly reduce productivity.

In the same way, when a new business capability is introduced, it is crucial to keep in mind the needs for training and organizational change that which may accompany the technical change. This is also true of the development environment. When a new development environment is put in place, the developers need to learn not only how each individual tool works (for example, how to use the compiler), but also how the tools work together to support the organization as it performs well defined processes.

The Business Integration Methodology (BIM) provides valuable information on organizational issues.

Relying on the Business Integration Methodology and its project organization guidelines (0940--Organize Project Resource Task Package), the following should be prepared:

A list of responsibilities covering both responsibilities for end products and those for on-going processes

A Responsibility, Accountability, and Authority profiles deliverable (RAA) for each role in the Development team, making sure that all the responsibilities listed earlier are covered

The RAA profiles deliverable consists of statements about the responsibilities, accountability, and authority of each of the positions in the development organization. These statements define the role of each position in terms of:

Responsibility--What objectives the position is expected to accomplish

Accountability--How and by whom the performance will be measured

Authority--The position's decision-making capabilities and limits

In accordance with the IDEA Model, the following management teams with responsibilities for the key management functions are defined as:

The Information Management team 902

The Quality team 904

The Environment Management team 906

The Release Management team 908

The Configuration Management team 910

The Problem Management team 912

The Program and Project Management teams 914

The Security Management team 916

Together, these teams support the efforts of the System Building team, which is charged with the analysis, design, build, and test of the system to be developed. These teams represent real roles, and on a given program the same people may play different roles.

Security Management

The evolution of new technologies and expanded access to a virtual world has increased the security risk of conducting business. It is therefore essential to recognize the need for a new unit in the organization, specifically dedicated to ensuring that security is handled appropriately. At the Program level, the Security Management unit needs to:

Ensure all security issues are effectively addressed throughout the program (all business and IT processes).

Act as facilitator and approving body for all new and existing initiatives that contain security components.

Own responsibility for the organization and facilitation of working groups that would address security issues.

Be responsible for development and maintenance of the Security Plan.

FIG. 10 is an illustration showing a security organization according to one embodiment of the present invention. A Security Management Team may have a security management 1000, under which are an administration team 1002, a projects & planning team 1004, and a business process security team 1006. The size of the Security Management team, and the way in which it is integrated into the development organization depends on the degree to which security is a factor for each specific environment. For example, the security risks associated with an Internet-based online banking system are far greater than those of a fully isolated client/server system, and therefore warrant a larger team with broader responsibilities and greater influence.

Information Management

The Information Management team is responsible for ensuring that the project's knowledge capital and information resources are managed effectively. This includes:

Ensuring integrity

Ensuring accessibility

Ensuring quality and consistency

Information Management encompasses Repository management, but generally has a broader scope than merely the repository contents, because most repositories are not capable of holding all the information resources of a project. It is, for example, common to have key project information reside in a combination of repositories, teamware databases, flat files, and paper documents. It is the Information Management team's responsibility to ensure consistency across all these formats. The responsibilities of the Information Management team therefore cover:

Repository Management

Folder Management

Object Management

Media Content Management

Information and data reuse coordination

In addition to managing the information for the System Building team, the Information Management team must also manage the information resources of the other management processes--quality management, environment management, and project management.

In order to delineate the responsibilities of the Information Management team, it is useful to state those areas that are out of scope. The following are not included:

Performance of daily backups--this is handled by the Environment Management team

Database administration--this is part of the Architecture team responsibilities

Performance tuning of the information repositories--this is handled by Environment Management

Repository Management

The Information Management team is ultimately responsible for the contents of the repository. They need to have an intimate understanding of the repository structure and the rules that govern how different objects should be stored in the repository.

Although most of the input to the repository are entered by designers, the Repository Management team must manage this population process. Rather than taking a policing role on the project, they should work as facilitators--helping the designers do things correctly the first time, thereby maintaining the integrity of the repository. Without strong repository management, the benefits of using a repository quickly diminish.

In many situations the Information Management team must make decisions that affect functional areas. To empower the Information Management team, the Application teams should include the Information Management team in relevant design discussions. This facilitates the validation of design outputs.

Folder Management

Folders (or directories) can be very useful in gaining control over the overwhelming amount of information produced on a large project. Their utility greatly increases if they are managed appropriately. This management is based on easy-to-follow, easy-to-enforce standards.

Object Management

The responsibilities involved with object management are very similar to those involved with repository management. However, in order to facilitate and promote reuse, it is recommended to have a librarian whose responsibilities include:

Reviewing designs

Packaging classes and components for reuse

Managing maintenance and upgrades of common components (a strong relationship with Configuration Management team is required)

Media Content Management

The methods of handling media content are somewhat different from those surrounding more traditional development content such as code or documentation, for this reason, a role should be defined that is responsible for the management of all media content.

Quality Management

The Quality team is responsible for defining and implementing the Quality Management Approach, which means defining what Quality means for the Program Leadership, and then implementing the procedures, standards, and tools required to ensure the delivery of a quality program. The Quality Management Approach addresses concepts such as expectation management, quality verification, process management, metrics, and continuous improvement.

Since quality is the result of the interaction of many teams working on multiple processes, the Quality team is responsible for ensuring effective cooperation between teams and good integration of the development processes. The Quality team must therefore forge strong links with all the other project teams.

It is important to note that the Quality team is not only responsible for ensuring the quality of the system building process. The Quality team is also directly involved in ensuring the quality of the other IDEA management processes.

Program & Project Management

The Program Management team is responsible for delivering business capability. In this respect, it is responsible for the System Building and other management teams. In addition, other management responsibilities that do not have a specific team or role defined within IDEA also belong to the Program Management team. These include:

Contingency Management

Financial Management

Issue Management (decisions to be made regarding the development of the business capability, not to be confused with problem management)

Program Performance Reporting

Resource Management

Risk Management

Vendor Management

The Project Management team is responsible for producing a deliverable or set of deliverables. As such, it is responsible for:

Planning and control of delivery

Milestones and schedule

Resource consumption

Risk and quality (at deliverable level)

Configuration Management

The Configuration Management team is responsible for defining the approach the program takes to deal with scope, change control, version control, and migration control, and for putting in place the policies, processes, and procedures required to implement this approach.

In other words, the team is responsible for maintaining the integrity of software and critical documents as they evolve through the delivery life cycle from analysis through deployment.

Release Management

Delivering a system on a release-based approach means delivering the system in a series of consecutive releases, increasing or refining functionality progressively. Some of the main drivers to such an approach include:

To release business benefits early

To mitigate impact on the organization

To keep the change program up to date

To optimize processes

To test proof of concept

To reduce risk

The Release Management team is responsible for:

Planning the capability release design and development effort, based on the capability development approach and timeline.

Measuring and monitoring progress using established processes to ensure that a capability release is delivered on time, within budget, and that it meets or exceeds expectations.

Managing project interdependencies to ensure delivery of the capability release.

Ensuring that resources are used effectively across projects for the release.

As with many other management responsibilities described in IDEA, Release Management is more a role than a function. It is good practice to have as many areas as possible represented in the Release Management team; for example, Design, Construction, Configuration, and Environment Management team members would make up a typical Release Management team, each providing input based on their own perspective.

Environment Management

Just as a business application requires support and system users require service, the development environment requires system operations daily, and developers require ongoing support in order to use the environment effectively (In fact, the complexity and frequence of these operations is often greater than that of the execution environment).

To ensure that this area receives the necessary attention, an Environment Management team 1100 should be assigned these tasks. FIG. 11 is an illustration showing the Environmental Management Team responsibilities.

The Service Group 1102 serves as a single point of contact for developers. It interfaces with the Architecture team to provide answers to questions from developers. To avoid adding overhead to the issue resolution process, the support group must be staffed adequately to ensure that all questions are answered. For example, the support group should recruit people from the Technology Infrastructure team at the completion of Technology Infrastructure development.

Problem Management

Problem Management is concerned with the discrepancies that result from the testing process and the management of design problems detected during verification or validation steps throughout the development process.

The Problem Management team is responsible for defining the problem tracking and solution process, and for providing tools and procedures to support the solution process.

System Building

The Business Integration Methodology (BIM) describes System Building under the following activities:

Design application

Build and test application

Design technology infrastructure

Build and test technology infrastructure

For this reason, the System Building teams are organized into application and technology Infrastructure.

Application Team

The Application team 1200 consists of three separate subteams: Application Architecture 1202, Application Development 1204, and System Test 1206. FIG. 12 is an illustration showing the Application Team structure and responsibilities.

The structure of the Application team evolves as the development process continues--as the development of the application architecture components is completed, the Application Architecture team's roles may change. While the team continues maintaining the application architecture components, some team members may be deployed to the Application Development team. Here their roles can include helping application developers to correctly use the architecture components, providing development support, and performing code reviews, and so forth.

As systems become more user-facing, important new roles are emerging that must be integrated into the Application Development teams:

a) Media Content Design

For any system with a user-facing component, it is extremely important that media and design specialists are involved as team members at an early stage in the design of the system. In systems with simple user interfaces, this helps to ensure usability and consistency. As user interfaces become more complex, the early involvement of design experts not only leads to more creative and attractive user interfaces, but also reduces the risk of further alteration to work at a later stage.

b) Usability

Often coupled with Media Content Design, it is vital that a role for usability is defined within the Application Development teams. This will ensure the usability of the system from the perspective of target user groups.

Technology Infrastructure Team

The technology infrastructure evolves throughout the project and responsibility for managing and evolving the infrastructure must be clearly defined. Therefore, rather than having a single amorphous `technical team` (responsible for operations, support, architecture evolution, and more), it is important to define a dedicated technology infrastructure team. By allowing the technology infrastructure team to focus on the technology infrastructure, rather than the day to day running of the environment, the project increases the chances that the technology infrastructure will provide good support for the business applications.

In practice, the Technology Infrastructure team is the team that will implement the IDEA framework.

The Technology Infrastructure team is responsible for:

Data design and management

Database administration

Database tuning

Execution architecture design and construction

Development architecture design and construction

Operations architecture design and construction

Network design

Technical standards design and documentation

System software selection

Performance tuning of the final system

Security infrastructure development

Note: The responsibilities of the Technology Infrastructure team may overlap with those of the Application Architecture team, and on some projects the two teams are often combined.

DEVELOPMENT PROCESSES FRAMEWORK

A thorough understanding of the development processes is a prerequisite for ensuring that the tools effectively support the organization and the processes they are intended to support.

The Development Process Model

The Development Process Model is a framework that facilitates the analysis of the many concurrent processes of systems development. This analysis helps understand process interaction, which, in turn, affects organizational interaction and defines a need for tools integration.

The Process model is simple--at its core is the system building process, which is surrounded by eight key management processes.

The core activity--systems building, depends strongly on support from the surrounding management processes, which all affect each other:

a) Information Management manages the information that supports the entire project--information that is used both in systems building and in other management processes

b) Security Management covers all areas of development security, from coding standards, to security verification.

c) Quality Management pertains to all areas of the development environment

d) Program and Project Management must manage all the management processes in addition to managing the systems building process

e) Environment Management supports the environment where management processes are performed, and where systems are being built

f) Release Management manages the simultaneous development of multiple releases

g) Configuration Management, often closely linked with release management covers the version control, migration control and change control of system components such as code and its associated documentation

h) Problem Management pertains to the problem tracking and solution process

Process Definition

For a given project, each of the processes must be defined at a greater level of detail than that which any methodology can achieve. This additional specification consists of a set of procedures and standards that specify how to perform the work and what to produce at each step.

Standards specify what the results should look like. They may include industry standards and more formal (de jure) standards, such as POSIX compliance, but most standards are project specific and determine, for example, how to structure and name system components and where to place system components. Standards make it possible for a large team to exchange information effectively and to work productively together.

Standards should focus on what must be common, and should not become a goal in themselves. Erring on the side of over-standardization stifles productivity. It is, however, often the case that unforeseen events (such as platform demise, tool evolution) will be easier to tackle the more unified the development approach has been used. Unfortunately, there is no substitute for experience when making the detailed decisions on exactly what should be standardized. Factors to take into account must at least include:

Life expectancy of the system under development--the higher the life expectancy, the more standards are warranted

Life expectancy of the development organization--the higher the life expectancy, the more standards are justified

Attrition--a stable organization can tackle more detailed standards than a volatile one

Expected change in the environment--a high rate of change provides greater opportunity to reap the benefits of a standardized approach

Procedures specify how to perform a task. They are generally guided by the methodology but provide information at a lower level of detail. They are highly environment-specific, and take into account the organization, the standards, and the tools in the environment. Procedures often specify the techniques to be used. They may specify which tools to use and how to use the tools that support these techniques.

Many processes require individual judgment, and the way to perform these processes cannot be specified in detail. In such cases, it may be valuable to provide guidelines that do not have the mandatory flavor of procedures but rather that of valuable advice.

While it is easy to generate zeal to set up standards and procedures at the beginning of a project, it can sometimes be more difficult to ensure that these are enforced throughout the project. Two considerations are useful. Firstly, standards must be easy to follow. It should be easier to follow the standard than doing things any other way. This is generally achieved by supplying the training, tools, and support needed to facilitate a given work style. For example, developing and distributing application program shells, which respect the architecture and standards, facilitates programming and contributes to ensuring broad standards compliance. Secondly, the responsibility for enforcing standards must be clearly identified and assigned. Standards enforcement must take place as a natural part of the process and at well-defined check points before work flows to the next task, or (even more importantly) to the next group or team.

A very useful way of complementing the specification of procedures is to provide samples. Samples can sometimes convey a message much faster than pages of explanatory prose. Sample programs are generally very useful. Other samples may include logs, which demonstrate interaction with tools, a sample change request, or a sample request for technical support. Samples can sometimes be created efficiently by taking screen dumps. This can be much faster than specifying what the screen should look like in theory.

Samples and standards must be high quality--any quality breach will be multiplied when developers start using them. It is therefore imperative that samples and standards not be created in a vacuum but be based on concrete experience with the project's development environment. Some pilot development work often proves extremely useful when fine tuning the standards.

When documenting the process, it is useful to develop an approach and process description for each project segment and for each high-level process. This document summarizes the support available for that segment or process. It refers to all the standards, procedures, guidelines, and examples relevant to a collection of tasks. Such a summary document makes it easier for developers to navigate the standards and hence to follow them.

Process Integration

To ensure that the project team works effectively together, numerous processes must be integrated. A simple example is provided by the required integration between design and construction. A more subtle one is the integration of product quality inspection and the continuous improvement process.

As process integration frequently involves several teams, it is crucial to understand the interfaces between processes and teams to ensure good hand-offs. This understanding must have a direct impact on tools integration, so that integrated processes are supported by integrated tools. Tools that support multiple processes performed by the same individual must, at a minimum, be integrated at the user interface level and should ideally be integrated at the process level. Tools that support processes performed by different individuals may only have to be integrated at the data level.

See Tools--Process Management for more details.

Security Management

Processes must be put into place in order to ensure security is properly designed and built into the system that is being developed, including:

Definition of security requirements based on business risk

Development of security standards, guidelines and procedures

Implementation of security controls

Security validation

Security Requirement Definition

Security requirements are the outcome of the security Risk Assessment. This is the process of identifying business risks, identifying system vulnerabilities or weaknesses that can impact those risks, and recommending mechanisms to control the vulnerabilities. Specific confidentiality, integrity and availability requirements for the new system and the development environment are defined through this process.

Security Standards, Guidelines and Procedures

Security standards, guidelines and procedures provide security direction to the implementation. They will help define how the security requirements developed through the Risk Assessment must be addressed in all areas of the development environment. They will include security standards for the development environment infrastructure, procedures for the development processes, standards for the design of the security architecture and security guidelines for programming. It is especially important to ensure the security of the development environment because if these systems are broken into and back doors are introduced, it may lead to later compromise of the production system. It will be the responsibility of all developers that these security controls are implemented and adhered to throughout the development process.

Security Validation In order to ensure the security of the system, periodical security audits should be arranged, in order to verify that the processes and architecture and application components that are being developed conform to security proven practices. This may be done by an external body specializing in security (such as Global TIS--Security) in the form of interviews, architecture and code reviews, and automated tool assessment.

Information Management (902)

A vast amount of information is generated within the development environment, which needs to be carefully managed (for example, design documentation, application code, media content, test plans and test data). Information Management generally involves Repository Management, Folder Management and, where applicable, Object Management and Media Content Management.

Since a number of teams rely on the service provided by the information management team, it is important that the level of service to be provided be chosen carefully, documented, and communicated. The arrangement should take the form of a Service Level Agreement (SLA). Such an SLA typically defines how quickly a new data element is created and how repository changes are communicated. More generally it defines the division of responsibilities between the information management team and the other project teams at a detailed level.

Repository Management (802)

Repository Management includes activities such as:

Monitoring and controlling update activities in the repository

Receiving and validating data element change requests

Creating and modifying data elements

Enforcing project standards regarding repository objects

Validating the contents of the repository to avoid redundancy and inconsistencies

Ensuring accuracy of the repository contents so that the repository reflects the applications being developed

Importing and exporting from one repository to another

Maintenance of the information model (or metamodel), which describes how data is represented within the repository

As many repositories do not provide sufficient versioning functionality, it is common to have more than one repository on large projects. Typically, there may be one repository for development, one for system test, and one for production. This allows better control, but also requires significant resources to move repository objects from the development environment to the system test environment. By merging the development and system test repositories, the medium-sized project has a potential for productivity gains. If these gains are to be realized, great care must be taken when making corrections during system test. As a common repository is shared, any error analysis involving repository objects must take into account the possibility that these objects could have changed since the previous migration to system test. This situation can be managed by meticulously maintaining a comprehensive change log.

Another reason for maintaining several copies of the repository is the existence of concurrent projects focusing on different releases. If this is the case, it may be beneficial to maintain delta repositories, which document those components that have been modified. This requires strict repository management but the reward can be significant. It allows the merging of several releases, which have implemented complementary functionality, but which have modified a few shared components.

A single development environment may have to deal with multiple repositories:

For functional reasons, one repository might be integrated with an upper-case design tool and the other with a lower-case generation tool

In a multi-site environment, repositories may be distributed over different locations. In order to keep these repositories synchronized, well defined development processes must be implemented.

Repository Management can be divided into the following areas:

Security

Maintenance

Validation and mass change

Analysis, reporting, and querying

Security

Restricted access to various repository object types is necessary to ensure high quality repository content, because developers sometimes take shortcuts and make unauthorized changes to meet their deadlines. When standards have been set, a good way to enforce them is to restrict personnel through the use of locking mechanisms. Access to repository object types will change throughout the project.

The data elements should usually be controlled by the Repository Management team, because they are the basic building blocks of the system and have broad reuse. Poorly defined data elements can cause inconsistency, redundancy, and generation errors. Data elements should therefore be locked at least by the time construction starts, and possibly earlier, depending on the discipline of the team. Project members must be allowed to browse the data elements, but only the Repository Management team should be allowed to modify or unlock data elements. In some repositories, it is difficult to restrict the creation of repository objects. If this is the case, it may be acceptable to let designers create data elements if these are reviewed and locked at the end of each day. Increased control can be obtained by having designers submit requests for new data elements to the repository administrator. This allows the repository manager to evaluate whether the new data element is justified, or whether an existing one should be used.

Repository Maintenance

a) Creating and Maintaining Data Elements

Requests for data element changes can be forwarded using a database or paper-based system. Based on functional and technical knowledge, the repository administrator evaluates the requests and may involve other teams to make appropriate decisions. The database used to request data element changes during design and programming should be separate from the project's change request database. This will simplify and speed up the change process. When data elements have to be changed during system test, however, the impact can be much greater, and the regular change request database should be used.

Whenever a data element is changed, impact analysis must be performed to understand the side-effects. Where-used reports are useful to determine these side-effects. The repository manager must be able to obtain the list of direct references and the list of all components affected indirectly (transitive closure). In the latter case, a message based on a record containing a group, which makes reference to a changed data element is considered to be indirectly affected by the change.

When adding a data element, no functional equivalent must exist, because redundancy creates difficulties for impact analysis and future maintenance.

b) Creating and Maintaining Other Repository Objects

The objects related to dialog definitions, reports, messages, and so forth, are usually maintained by the designers and programmers. When the dialogs and report programs are tested, approved, and ready to be promoted to the system test environment, the related objects must be locked. This is the responsibility of the Repository Management team.

Repository Validation and Mass Changes

Keeping thousands of data elements consistent and in compliance with project standards requires a sustained effort. This daily effort is crucial to avoid a massive clean-up, which would be necessary if the repository manager ever lost control of the repository.

Detailed, project-specific standards should exist for defining repository objects. These standards can form the basis for a repository validation program, which can run through the entire repository and report on detected deviations from standards. In some cases, this program can also enforce the standard.

Mass changes to the repository can be performed when the validation reports show the occurrence of many standards violations that follow a common pattern. This may occur in cases where:

Project standards have been incomplete

Project standards have changed

Repository management has been poor

New objects have been imported from another repository

Analysis, Reports, and Queries

Certain reports should be run daily, such as the list of new data elements or modified data elements. These reports can serve as an audit trail of changes and can be used to communicate changes to the entire team. Procedures should specify which reports are run daily and what their distribution should be.

The Repository Management team performs certain analyses repeatedly. Standard analyses such as impact analyses should be specified in detail to facilitate staffing flexibility.

When supporting specific kinds of repository analysis, the Repository Management team can provide custom reports or ad hoc queries that satisfy particular needs.

Folder Management (804)

It is important to set up and communicate a detailed folder structure with specified access rights from the beginning. Contents of folders must be checked regularly to ensure that folders contain what they are supposed to.

Two main strategies exist.

Folders can be organized by type of component so that one folder contains all the include files, one folder contains the source modules, one folder contains executables, and so on.

Folders can also be organized functionally so that all the common components reside in one folder and each application area stores its components in its own folder.

Choosing the strategy depends on how components are named, on the number of components, and on the tools used. If naming standards make it easy to identify the component type (for example, by using suffixes), organizing them by functional area is generally useful and straightforward to administer. Some tools assume that closely linked files (for example, source and object modules) reside in the same folder.

Another important distinction is the one between work in progress and completed documents that have been approved. This distinction can be supported by a folder structure with carefully chosen access rights.

This distinction makes it easy to retrieve a consistent copy of project documentation for someone who is new to the project.

While scratch folders may be useful in certain contexts, the proliferation of miscellaneous folders with cryptic names can make it very difficult to navigate the information. Some useful guidelines include:

Keep the folder structure under central control.

Within personal folders, allow users to create any folder structure.

Clearly assign ownership for the contents of each folder.

Document each folder, either in a central location, or in the form of a readme type file within the folder itself. The high-level documentation should include the purpose of the folder and the kinds of contents it should hold.

Perform regular clean-up, by backing up redundant or misplaced files and then removing them.

Media Content Management (806)

The unique nature of media content means that it cannot be treated in the same way as `standard` formats, such as source code or design documentation. The major differentiating factors are its sheer volume (media files can range from a Kilobyte to multiple Gigabytes), and the complexity of its associated formats (i.e. it is not easy to `look into` a media file and understand its contents). For this reason, some of the processes that support multimedia content management must be handled differently. The three major processes that are required to support media content management are:

Storage management

Metadata management

Version control

Storage Management

Storage management concerns the methods of storing and retrieving media content. The cost of data storage may be decreasing, but it is still the case that for large volumes of media it is often uneconomical to store everything on-line. For this reason, processes must be implemented to manage where data should be stored, and how it may be transitioned from one location to another. There are three ways to store data:

On-line (Instant access, for example, hard disk)

Near-line (delayed access, for example, CD-ROM jukebox)

Off-line (manual access, for example, CDs or tapes on shelves)

When deciding on where media content should be stored, there is always a trade-off between accessibility and cost (on-line storage being the most accessible and most expensive, and off-line the cheapest but least accessible). The decision of which method to use for which data may depend on a combination of its type, volume, version (i.e. latest or historic) and accessibility requirements.

Metadata Management

Data about the media that is being stored is an important commodity that must be managed. As the volume of media content grows, it is vital to be able to understand characteristics of the media, in order to be able to manage it correctly. Examples of metadata include:

Media type (for example, MPEG video, JPEG image)

Media settings (for example, sample rate, resolution, compression attributes)

Usage details (which module uses the content)

Media source (for example, Source, author, creation date)

Legal information (for example, whether the media is copyrighted)

Version Control

As with standard development code, when media content is created and edited, a revision history of changes should be retained. This way, if it is necessary to revert to an original piece of media content, it is not necessary to go all the way back to the original source (which in the case of finding an image in a CD-ROM library containing 10,000 images, for example, could be a difficult task). In practice, this may mean storing the original and final copies of media (especially where volume is an issue). For this reason, a process for managing multiple versions of media content must be put into place.

The more advanced media content management tools may provide much of the functionality required to support these processes, but where this is not the case, the processes must be implemented manually.

c) Legal Issue Management

When dealing with media, it is often the case that content may be subject to copyright laws. It is important that the legal implications surrounding all content in the system is understood, and where necessary, royalties paid to the appropriate parties.

Object Management (808)

Object Management processes are very similar to those involved with Repository Management. However, they should promote reuse through specific processes:

Design review

Classes and components packaging for reuse

Common components maintenance and upgrade

Quality Management (904)

Quality Management is described at length in the Business Integration Methodology (BIM).

The Quality Management processes are covered by the following tasks:

0623--Define Quality Management Approach

0732--Implement Quality Management Approach

The objective of these tasks is to ensure that, early in the life of a program, program leadership explicitly defines what quality means for the program. This results in the production of the quality plan. Then the infrastructure and processes are put in place to ensure delivery of a quality program.

The Quality Management Approach defines the following processes:

Expectation Management

Quality Verification

Process Management

Metrics

Continuous Improvement

Rewards and Recognition

Training and Orientation

Focus here is on those processes that have a direct impact on IDEA and its components (that is, Systems Building and the management processes).

Expectation Management Process

Expectations can be thought of as quality objectives expressed in measurable terms such as:

Functionality

Reliability

Usability

Efficiency

Maintainability

Portability

Security

Quality Verification Process

The targets for quality verification should be defined. Processes and deliverables are key candidates.

In development terms, the V-model is the preferred method by which the quality verification process is managed. The V-model ensures that deliverables are verified, validated, and tested. It is based on the concept of stage containment (enforcing for a given deliverable the identification of the problems before it goes to the next stage) and entry and exit criteria (describes conditions in which a deliverable passes from one stage to another).

The quality verification process owner may not be responsible for executing the V-model, but is responsible for making sure that the V-model is in place and complied with.

Metrics Process (810)

To fine-tune the development process, the important quality attributes must be measured. Sample metrics include:

Development environment availability

Time needed for a new user to learn to use a function of the development environment

User error rate per function

User satisfaction per function

Code complexity

Code structure

Productivity

Average number of defects per design packet at the moment construction starts

Average number of defects per program at the time of its first migration to system test

Once the key metrics are agreed upon, procedures must be put in place to:

Perform the measurements (these should flow from the development processes in a natural way)

Compare results with the goals documented in the quality plan

Analyze deviations, with key focus on the process that caused the deviation

Adjust the processes so that similar deviations do not occur in the future

Continuous Improvement Process (812)

The first stage of the Continuous Improvement Process (CIP) is to capture continuous improvement opportunities. These may include:

Gaps identified by metrics

Analysis of program performance-internal quality verification results

Process reviews

Capability Maturity Model (CMM) assessments (See Standards and Procedures)

Suggestions made by program team members; for example, through a suggestion box

The CIP then plans and manages improvement related activities such as:

Define explicit criteria for assigning priority

Consider raising the priority of low-priority opportunities that can be completed quickly

Maintain a mix of high-priority and sure successes to ensure the continued momentum

of the Continuous Improvement program

Define the opportunity selection process

Identify the resource allocation process

Define the scheduling process

Identify how the effort will be monitored

Identify the procedure for communicating results to the organization

Establish a continuous improvement organization to support the process

Prioritize and classify opportunities

Select projects

Allocate resources and scheduling

Monitor effort

Support a standard process improvement process across the project

While maintaining quality at a program level, the Quality Management team must liaise with each of the organizational units within the development environment in order to monitor the quality management processes within these units.

Standards and Procedures

The Capability Maturity Model (CMM) for Software describes the software engineering and management practices that characterize organizations as they mature their processes for developing and maintaining software.

The CMM provides a software organization with guidance on how to gain control over their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. The model defines five levels of software process maturity as well as how to move from one level to the level above.

For more details, refer to Consistently Delivering Value: The CMM--How to Help Your Project Measure Up.

The V-model is a framework that promotes stage containment by organizing the verification, validation, and testing in and across all the methodology elements throughout the delivery phase of the Business Integration Methodology.

For more details, please refer to the V-model overview job-aid in the Business Integration Methodology.

The IMPROVE Job Aid (provided with the BIM Guide) describes the process for solving problems or improving a process. In this Job Aid, you will find an introduction to the five step process your team can use to solve both simple and complex problems. The Quality Action Team (QAT) is responsible for applying IMPROVE to improve a process or solve a problem.

Program and Project Management (914)

Program Management

Program Management focuses on the continuous oversight needed to support the delivery of business capability through multiple projects and releases. Appropriate disciplines, techniques, and tools are used to plan and organize the work, and to manage the incremental delivery of the new business capability.

Program Management consists of three major activities, each split into a number of task packages.

a) Plan Program

0610--Understand Program Expectations

0620--Plan Management Processes

0640--Develop Program Master Plan

0650--Design Initial Teamwork Environment*

0670--Plan Delivery

0680--Create Program Plan

b) Mobilize Program

0710--Obtain and Deploy Resources

0730--Implement Management Processes

0750--Establish Program Management Office

0770--Implement Initial Teamwork Environment*

0790--Establish Orientation and Training

c) Manage and Improve Program

0810--Direct Program

0820--Execute Management Processes

0830--Analyze Program Performance

0840--Plan and Implement Program Improvements

0850--Operate Program Management Office

0860--Authorize Build and Test

0870--Authorize Deployment

0880--Operate Team Work Environment*

0890--Conduct Program Close-Out

*The Team Work environment, in the domain of the development environment, includes those parts of the development environment which are consistent across the entire program (e.g. Collaborative tools)

Project Management

Project Management focuses on providing specific deliverables through balanced management of scope, quality, effort, risk, and schedule. Project Management processes follow a cycle of planning the project's execution, organizing its: resources, and controlling its work. The Project Management team oversees all other teams within the development environment.

Project Management comprises a single activity containing a number of task packages.

a) Plan and Manage Project

0920--Plan Project Execution

0940--Organize Project Resources

0960--Control Project Work

0990--Complete Project

Configuration Management (910)

Configuration Management is not only the management of the components in a given environment to ensure that they collectively satisfy given requirements, but it is the management of the environment itself. The environment consists not only of system components, but also of the maintenance of these components and the hardware, software, processes, procedures, standards, and policies that govern the environment.

Configuration Management in systems building consists of four major interdependencies:

Packaging

Version control 814

Migration control 816

Change control 818

Standards and Procedures

a) Packaging Plan

Packaging is the combination of systems software and application component configurations (source code, executable modules, DDL and scripts, HTML) together with their respective documentation. It may also include the test-data, test scripts, and other components that must be aligned with a given version of the configuration. Packaging allows the grouping of components into deliverable packets of application software that can be developed, tested, and eventually delivered to the production environment. Packaging defines the underlying architecture that drives version, change, and migration control. Each of these control processes defines how changes to configuration packages are versioned and migrated to the various development and test phases in the systems development life cycle.

A sample packaging strategy would take into consideration some of the following factors in determining a unique method to handle a given configuration packet in terms of version, change, and migration control:

Base package type--identifies the various types of application components that are developed during systems building such as executables, JCL, HTML scripts, and Java applets.

Package release type--identifies the types of commonality that components can have. There are usually four basic types of components that are developed during systems building:

Technology architecture packages--these packages are developed by the Technology Architecture team and are used by all other projects in a program

Program-wide packages--these packages are developed by the Application Development teams but are used by other projects in the program. They are common components that are not owned by the Technology Architecture team

Application common packages--these packages are developed by the Application Development team and are used internally on the project by application developers

Application packages--these packages are the most rudimentary of all packages developed. They consist of basic application components developed by application developer

Package platform type--identifies the eventual delivery platform of the package. Identifying this early on in development and encapsulating this information within the package definition, allows developers to envisage the production environment at an early stage during the systems development life cycle.

Given these three basic package definitions, a configuration management cube can be defined, which uniquely identifies version, change, and migration control characteristics of a given package. The cube can be used to implement a table-driven configuration management control system for all software developed on the program. The configuration control system consists of version and migration control. Therefore, the cube defines all processes associated with version control and migration of a package.

b) Version Control (814)

Version control and compatibility are key considerations when managing these packages. Note that version control not only applies to software components, but also to all components of a given package, including test scripts, test data, and design documentation. It is also of great importance to keep track of which version is in which environment. If incompatibilities are discovered, it must always be possible to "roll back" to a previous consistent state, that is, to revert to an earlier version of one or more components. It must be possible to define releases of a configuration--a list of version numbers, one for each component of the package which together form a consistent configuration. The smallest unit that can be version controlled should be the package as defined in the packaging plan. This ensures that the lowest common denominator in all version control activities is managed at the package level.

c) Migration Control (816)

A systems building environment can have many development and test stages. On a large project these may include:

Development and unit test

Assembly test

System test

Integration test

User acceptance test

Migration of packages or consistent configurations from one stage to another is a central part of Configuration Management. The key to successful migration is the knowledge of what constitutes each stage. Examples of migration include:

Migration from development and unit test to system test

Migration from user acceptance test to production

Migration of development tools from the Technology Architecture team to the developers on the project

Migration of architecture components from the Technology Architecture team to the developers on the project

Stages and their constituents exist as a result of certain user and technical requirements. The technical requirements are derived from the user requirements. It is crucial to develop a migration plan that maps out the progression on configuration packages throughout the systems development life cycle. FIG. 13 is an illustration showing a model migration plan in accordance with one embodiment of the present invention.

The FIG. 13 model allows the development and testing of architecture components independent of application components. The Technology Architecture team can develop 1300, assembly test 1302, and system test 1304 their components before delivering them to the development environment for the application developers. This ensures that the architecture is thoroughly tested before being used by the Application teams. The model also illustrates the progression of architecture and application components through the systems development life cycle. The application developers can then develop 1306, assembly test 1308, and system test 1310 their components before user acceptance tests 1312. The model is a temporal one and thus suggests that architecture must be present at a given stage before the introduction of application components.

The version control plan must align with the migration control plan. The version control plan defines the points where version control activities will take place. In the above example, version control will take place at the development stages, architecture development and unit test, and application development and unit test.

Migration control defines how these version control configuration packages will be migrated successfully from one stage to the next until the package is eventually released to the production environment.

d) Change Control (818)

Change requests as a consequence of changing requirements and changes requested due to nonconformities (or defects), either in the application software, or in the system software must be analyzed, authorized, scheduled, staffed, and tracked in a defined way. What, why, when, and who made a change must be tracked from the point of analysis to the reintroduction of the defective or changed component at the appropriate stage. Change control therefore governs what software component is changed, version controlled, and when it is remigrated to a given development stage. It is important to link the general change request with the requests produced during formal testing phases. This makes the processes clearer.

Configuration Management becomes more complex in a component-based development environment as the system is broken down to a greater level of granularity.

Release Management (908)

Release Management involves coordinating activities that contribute to a release (for example, cross-project management) and the coordination of products that contribute to a release (such as architecture, integration, and packaging). It is concerned with managing a single release rather than cross-release management.

The Release Management approach documents critical decisions regarding the management, tracking, and integrity of all components and configurations within a given release. The Release Management approach must be closely coordinated with the definition of the Configuration Management approach and the Problem Management approach. Release Management involves two main components:

The coordination of activities that contribute to a release

The coordination of products that contribute to a release

The coordination of products that contribute to a release is the maintenance of a bill of materials for a release. It is an inventory of all software and hardware components that are related to a given release. The development environment is directly affected by the Release Management strategy. The way a program decides to plan releases affects the complexity of the development environment. It should be noted that delivering a system in a series of releases significantly increases the effort.

Standards and Procedures

If the release plan dictates that there will be parallel development of two releases of software, the development environment and configuration management must be able to support the release plan. In the most general development case, a program can have a single release capability mechanism 1400 but must simultaneously perform maintenance activities 1402 for components that are in production 1404. There must be an ability for the program to design, build, and test the applications for production. FIG. 14 is an illustration showing a single release capability development pipeline in accordance with one embodiment of the present invention.

The ability to perform all development stages for a given release can be defined as a development pipeline. The pipeline consists of all development and testing stages necessary to release the software to production.

The pipeline strategy of a program depends directly on the release strategy. A program is potentially developed on three different timeliness:

Short term 1500--production bug fixes

Middle term 1502--production service packs

Long term 1504--new releases of software

To support this release plan, the development environment must be separated into pipelines that are replicas of a single migration path to production 1404. A pipeline consists of all the necessary development and testing stages required to deliver a piece of software to production. Therefore, because of simultaneous development and testing of three code bases, there needs to be three development and testing pipelines that deliver software to production.

The pipelines must be capable of allowing the developer to design, build, and test applications as well as architecture components. FIG. 15 is an illustration showing a multiple release capability development pipeline in accordance with one embodiment of the present invention.

As can be derived from the above illustrations, the more flexible a release plan, the more complex the development environment. As the number of development pipelines increase, the complexity of working in the development environment also increases. All development environment tools must support the pipelining strategy and so must the configuration management and problem management processes. The pipeline strategy for a program must incorporate code base synchronization. Code base synchronization must occur among the three pipelines to ensure that the three code bases eventually result in one version in production. FIG. 16 is an illustration showing a multiple release capability development pipeline 1600 with code base synchronization among three pipelines.

Environment Management (906)

Since the development environment is a production environment, it follows that environment management must be planned, organized, and executed to ensure a predictable and productive environment. The present invention can include a comprehensive framework for the Management Of Distributed Environments (MODE), describing four central functions:

Managing Change 820

Service Management 822

Service Planning 824

Systems Management 826

MODE provides an excellent framework for specifying the management responsibilities that apply to the development environment. These responsibilities are often assigned to the technical group, but as discussed above, there are:benefits associated with establishing a dedicated environment management team.

The Environment Management component described here uses MODE as a framework, adopts MODE terminology, and focuses on those management tasks, which are particularly important in the development environment.

Adopting a structured approach to environment management, which applies the same principles to development as it does to production, has several advantages:

High-quality support for developers

Significant experience with the operations management tools in an environment, which is generally smaller and which carries lower risk than the full production environment

The ability to tune the environment management approach before production roll-out

In some respects, the development environment is simpler than the production environment. It is, for example, generally smaller in terms of the number of hardware components and the number of locations. In other respects, however, the development environment is more complex. For example, the amount of change in this environment is generally higher than in the production environment. In fact, the environment can be so fluid that extreme care must be taken to maintain control. On a large engagement, one dedicated technical support person per ten designers and programmers is recommended. The greatest need for technical support is generally during detailed design and programming. It is, however, necessary to start building the technic