Abstract:
An apparatus, system, and method are disclosed for delivery of software. A snapshot module is included to create a snapshot of development software libraries still in a development phase, the development software libraries comprising substantially an entire replacement set of software code. A testing module is included to apply a set of tests to the snapshot to ensure that the snapshot is substantially free from defects and a delivery module delivers the snapshot to a user. The snapshot may be configured for a mainframe computer operating system such that a previous version of the software code is replaced in a single operation. The mainframe computer operating system may be the z/OS operating system.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of the Invention  
         [0002]     This invention relates to software delivery and more particularly relates to software delivery of a developmental software library in a developmental phase for a mainframe computer.  
         [0003]     2. Description of the Related Art  
         [0004]     In developing applications for mainframe operating systems, there is a need to release software to Independent Software Vendors (“ISV”) during a developmental phase so they can work in parallel with the application design team to develop software tools for the application. Updates of the release software should be frequent to capture changes and defect corrections made by the software design team and to respond to defects hindering development of ISV tools. Typically, as shown in the flowchart  100  of  FIG. 1 , when an application is developed and tested such that the application can be sent to the ISVs, the application code is used to create  102  a software driver that can be sent to the ISVs. A software driver typically consists of development software libraries. Typical elements of the software libraries are source code, object code, modules, panels, macros, and sample code.  
         [0005]     Next, the software driver is tested  104 . Typically, the testing includes regression testing using test cases. For example, testing for International Business Machine&#39;s (“IBM”) Information Management System (“IMS”), a database and transaction management application, may include approximately one-hundred and fifty test cases. In addition, testing may include verification of installation and sample systems. An example of such a testing method is the IMS Installation Verification Program (“IVP”), which includes a set of panels to guide a user through customization and testing of sample IMS systems.  
         [0006]     If a defect is detected  106  during testing, the defect is reported  108 , corrected  110 , a new software driver is created  102 , and the driver is tested  104  again. The testing  104  after a defect is corrected  110  may be extensive or minimal depending upon the defect.  
         [0007]     Once the above mentioned testing  104  is completed, the software driver is converted  112  to a proprietary format for a software maintenance application such as System Modification Program Extended (“SMP/E”) that is typically integrated with the z/OS or OS  390  mainframe operating systems. In order to ensure that the conversion  112  did not introduce errors, the converted software is tested  114  again. If errors are detected  116 , they are again reported  108 , corrected  110 , and a new software driver is created  102 . The driver may have to be retested  104  and reconverted  112  and the conversion retested  114  many times. Once this conversion testing  114  is completed, the SMP/E compatible software driver is typically loaded  118  onto tapes and delivered  120  to the ISVs. SMP/E support libraries are also included with the SMP/E compatible software driver.  
         [0008]     Once the ISVs receive the tapes, they in turn install  122  the SMP/E compatible driver on their mainframe computers, and if the software driver is not a software driver update, the ISV may then use  124  the software driver. Traditionally, the same method  100  is repeated in order to create  102  software driver updates. Typically, a software driver update includes just the changed files or libraries of a software driver. If a software driver update is created  102  and converted  112  to the SMP/E format, typically only incremental updates are included and bundled together in the software driver update, each incremental update relates to a particular change in the software application. Incremental updates may depend on each other depending on the kinds of changes that have been made.  
         [0009]     The process of converting  112  a software driver update to the SMP/E format and testing  114  may be very cumbersome for the software driver design team, especially if there are a large number of incremental updates in a software driver. For example, rather than meeting a goal of monthly updates, the IMS design team may only be able to deliver one software driver update to the ISVs in a six month development period. This creates a problem since the ISVs are not able to receive timely updates and errors are not corrected quickly. ISVs may have to work with a software driver having uncorrected defects for an extended period of time which may delay completion of software driver tools developed by the ISVs.  
         [0010]     The process of installing  122  an SMP/E compatible driver update is cumbersome for the ISVs because the SMP/E tool installs  122  the driver update incrementally. When an ISV applies the driver update, there may be a large number of incremental updates included and some of the incremental updates may require manual involvement. The manual involvement during installation  122  of a driver update may be cumbersome and repetitive when a large amount of incremental updates are included in the driver update. Once the software driver update is installed  122  and manual involvement is finished, the software driver update may be used  124 .  
         [0011]     From the foregoing discussion, it should be apparent that a need exists for an apparatus, system, and method for efficient software delivery. Beneficially, such an apparatus, system, and method would reduce the time and effort required from the software driver design team and from the software driver users, such as ISVs, to install an update of a software driver that replaces essentially the whole software driver code, would be responsive to the needs of ISVs for quick error correction, and would allow software driver updates with a large number of incremental updates to be packaged in a single code update.  
       SUMMARY OF THE INVENTION  
       [0012]     The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available software delivery methods. Accordingly, the present invention has been developed to provide an apparatus, system, and method for delivery of software that overcomes many or all of the above-discussed shortcomings in the art.  
         [0013]     The apparatus for delivery of software is provided with a logic unit containing a plurality of modules configured to functionally execute the necessary steps of creating a snapshot of developmental software libraries, testing the snapshot, and delivering the snapshot to a user via an electronic communications channel. These modules in the described embodiments include a snapshot module that creates a snapshot of development software libraries still in a development phase, the development software libraries comprising substantially an entire replacement set of software code, a testing module that applies a set of tests to the snapshot to ensure that the snapshot is substantially free from defects, and a delivery module configured to deliver the snapshot to a user.  
         [0014]     In one embodiment, the snapshot is configured to replace code for a mainframe computer operating system such that a previous version of the software code is replaced in a single operation. The snapshot may comprise an incremental update or a plurality of incremental updates in a single package. In another embodiment, the mainframe computer operating system is the z/OS operating system.  
         [0015]     The apparatus, in one embodiment, is configured to exclude a conversion test for a software maintenance application. In a further embodiment, the software maintenance application may be System Modification Program Extended (“SMP/E”). In one embodiment, the snapshot is configured to be substantially free from software maintenance application dependencies.  
         [0016]     The apparatus may include a tracking module that tracks a code defect in the snapshot and to report the defect. In another embodiment, the code defect is discovered and reported by a group consisting of a user, a code developer, and a software application. In yet another embodiment, a documentation module is included to document snapshot attributes.  
         [0017]     In one embodiment, the delivery module delivers the snapshot using an electronic communication channel. In an alternate embodiment, the delivery module further includes a posting module that posts the snapshot to an electronic site and a download module that downloads the snapshot from the electronic site.  
         [0018]     A system of the present invention is also presented for delivery of software. The system may be embodied by a processing unit. In particular, the system, in one embodiment, includes a snapshot module in the processing unit to create a snapshot of development software libraries still in a development phase, the development software libraries including substantially an entire replacement set of software code, a testing module to apply a set of tests to the snapshot to ensure that the snapshot is substantially free from defects, a delivery module to deliver the snapshot to a user, a tracking module to track a code defect in the snapshot and to report the defects, and a documentation module to document snapshot attributes.  
         [0019]     The system may further include a mainframe computer in electronic communication with the processing unit via a communication channel. The snapshot, in another embodiment, is configured to replace code for a mainframe computer operating system such that a previous version of the software code is replaced in a single operation. In a further embodiment, the mainframe computer operating system is the z/OS operating system.  
         [0020]     The set of tests, in one embodiment, exclude a conversion test for a software maintenance application. In an alternate embodiment, the software maintenance application may be System Modification Program Extended (“SMP/E”). In a further embodiment, the snapshot may be substantially free from software maintenance application dependencies. In another embodiment, the code defect is discovered and reported by a group consisting of a user, a code developer, and a software application. In an alternate configuration, the delivery module includes a posting module that posts the snapshot to an electronic site and a download module that downloads the snapshot from the electronic site.  
         [0021]     A method of the present invention is also presented for delivery of software. The method in the disclosed embodiments substantially includes the steps necessary to carry out the functions presented above with respect to the operation of the described apparatus and system. In one embodiment, the method includes creating a snapshot of development software libraries still in a development phase, the development software libraries comprising substantially an entire replacement set of software code, applying a set of tests to the snapshot to ensure that the snapshot is substantially free from defects, and delivering the snapshot to a user.  
         [0022]     The snapshot, in one embodiment, is configured to replace code for a mainframe computer operating system such that a previous version of the software code is replaced in a single operation. In another embodiment, the mainframe computer operating system is the z/OS operating system.  
         [0023]     In a further embodiment, the set of tests exclude a conversion test for a software maintenance application. In another embodiment, the software maintenance application may be System Modification Program Extended (“SMP/E”). In one embodiment, the snapshot is configured to be substantially free from software maintenance application dependencies.  
         [0024]     The method, in one embodiment, may include tracking a code defect in the snapshot and to report the defect. In another embodiment, the code defect is discovered and reported by a group consisting of a user, a code developer, and a software application. Another embodiment includes documenting snapshot attributes. The method may also include delivering the snapshot using an electronic communication channel. Delivering the snapshot using an electronic communication channel may include posting the snapshot to an electronic site and downloading the snapshot from the electronic site.  
         [0025]     Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.  
         [0026]     Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.  
         [0027]     These features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0028]     In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:  
         [0029]      FIG. 1  is a schematic block diagram illustrating one embodiment of a conventional process flow for software delivery;  
         [0030]      FIG. 2  is a schematic block diagram illustrating one embodiment of method for delivery of software in accordance with the present invention;  
         [0031]      FIG. 3  is a schematic block diagram of a system for delivery of software in accordance with the present invention;  
         [0032]      FIG. 4  is a schematic block diagram of an apparatus for delivery of software in accordance with the present invention;  
         [0033]      FIG. 5  is a schematic flow chart diagram illustrating one embodiment of a method for delivery of software in accordance with the present invention; and  
         [0034]      FIG. 6  is a schematic flow chart diagram illustrating a more detailed embodiment of a method for delivery of software in accordance with the present invention.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0035]     Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.  
         [0036]     Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.  
         [0037]     Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.  
         [0038]     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.  
         [0039]     Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.  
         [0040]      FIG. 2  depicts a schematic block diagram of a method  200  for delivery of software in accordance with the present invention. In this method  200 , once the developmental software libraries are developed and tested to a point where they are ready to be sent to the ISVs, the developmental software libraries are used to create  102  a software driver that can be sent to the ISVs. The software driver is referred to herein as “a software driver snapshot” or simply “a snapshot” because a substantially complete copy of the developmental libraries is created at a particular point in time. The software driver snapshot is then tested  104  as was discussed in relation to  FIG. 1 . Again, if a defect is detected  106 , the defect is reported  108 , corrected  110 , a new software driver snapshot is created  102 , and the software driver snapshot is tested  104  again.  
         [0041]     In the present invention, instead of creating SMP/E compatible libraries with incremental updates, the entire software driver snapshot is sent to the ISVs. For an ISV, instead of applying a snapshot driver update with incremental updates, as is the case with SMP/E, which may require a great deal of manual user involvement, for the present invention, the ISV need only install the complete software driver snapshot. In addition, rather than delivering  120  tapes with the software driver snapshot, the software driver snapshot is uploaded  202  to a File Transfer Protocol (“FTP”) site. The ISVs then download  204  the software driver snapshot. This process takes much less time and human resources than the conventional method  100 , because there is no need to convert the software driver to the SMP/E format, test the converted software driver, or for a large amount of manual user involvement from an ISV.  
         [0042]     Installation  206  is achieved simply by installing the new, complete software driver. The software driver is then ready for use  126 . This installation process  206  is much less cumbersome for the ISV than installing software updates using SMP/E compatible software drivers and the SMP/E application.  
         [0043]     With the new method  200 , the ISV uses well known software tools to unpack and install  206  the new program essentially in a single step. Substantially all old code libraries on a target system are replaced. For example, the installation of the IMS driver uses readily available software tools called TRSMAIN and ADRDSSU to explode and install the software driver. A technician or end-user may then customize the software driver to their needs. The installation is simple, repeatable, and saves the design team and ISVs valuable development time. In contrast, using SMP/E requires more time and human resources, especially for software driver updates with many incremental updates.  
         [0044]      FIG. 3  is a schematic block diagram of a system  300  for delivery of software in accordance with the present invention. In the system  300 , a processing unit  302  is connected to a network  304  which then connects to a mainframe computer  304 . The processing unit  302  is typically located at a software manufacturer&#39;s development facility and may be embodied by a mainframe computer, a desk-top computer, or a workstation.  
         [0045]     The network  304  may be embodied by a wide area network, a local area network, a fiber optic connection, the Internet, or any other electronic media allowing direct transfer of a software driver. Alternatively, the processing unit  302  is directly connected to the mainframe computer  304 .  
         [0046]     The mainframe computer  306  is typically located at the end-user facility. The end-user may comprise an ISV, a third-party vendor, or any other user of the software driver. The mainframe computer  306  alternatively may comprise any suitably configured computer at the end-user facility that can download or otherwise receive the software driver. Once loaded, the software driver is installed on the mainframe computer  306  and an ISV can then test its tools with the new software driver. One skilled in the art will recognize alternate configurations of computers, networks, mainframes, and other hardware for delivery of software from a software driver developer to a user.  
         [0047]      FIG. 4  is a schematic drawing of an apparatus  400  for delivery of software in accordance with the present invention. The apparatus  400  may include in the processing unit  302  a snapshot module  402  configured to create a snapshot at a particular point in time of a development software library. A snapshot preferably comprises a complete set of binary and source code configured to replace a corresponding set of software code at a user site.  
         [0048]     In one embodiment, the snapshot may require minimal customization to operate at the customer site. The snapshot may be created by copying the complete development software library source code, object code, modules, libraries, macros, panels, samples, and other parts of the development software libraries such that the snapshot is a complete software driver. The snapshot does not include SMP/E libraries and is not converted to the SMP/E format. The time when a snapshot is created may be determined by a software driver design team based on achieving a state of usability deemed acceptable to the design team for delivery of the software driver to the users. Typically, the development software library is tested extensively prior to creation of a snapshot  402 .  
         [0049]     The processing unit  302  may also include a testing module  404  configured to test the snapshot of the software driver. A delivery module  406  is configured to deliver the snapshot to a user. In one embodiment, the processing unit  302  includes a documentation module  408  configured to document software driver attributes. In another embodiment, the processing unit  302  includes a tracking module  410  configured to track and report software driver defects. Each module will be further defined in relation to  FIGS. 5 and 6 .  
         [0050]     The schematic flow chart diagrams that follow are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.  
         [0051]      FIG. 5  is a schematic flow chart diagram illustrating one embodiment of method  500  for delivery of software in accordance with the present invention. The method  500  begins  502  when the snapshot module  402  creates  504  a snapshot of a complete development software library. The testing module  404  then tests  506  the snapshot. Testing may include regression testing using test cases, IVP testing, or any other testing useful in determining proper functionality of the snapshot. One skilled in the art will recognize other testing useful to the software design team in determining the stage of completeness and functionality of the snapshot.  
         [0052]     The delivery module  406  then delivers  508  the snapshot to a user and the method  500  ends  510 . As mentioned in relation to  FIG. 2 , in a preferred embodiment, the delivery module  406  uploads the snapshot to an FTP site and then the user downloads the snapshot from the FTP site. The user may use any FTP client capable of retrieving files from a secure FTP site. The snapshot may also be delivered  508  by sending the snapshot in an email, saving the snapshot on a computer accessible to the user, storing the snapshot on computer readable media, or through any other electronic channel.  
         [0053]      FIG. 6  is a schematic flow chart diagram illustrating a more detailed embodiment of a method  600  for delivery of software in accordance with the present invention. The method begins  602  when the snapshot module  402  creates  604  a snapshot of the complete software delivery. The testing module  404  applies  606  a set of tests to the snapshot as described above. Once the testing is complete, the test results are evaluated  608  to determine if the results are acceptable for sending the snapshot to users. If not, certain defects are corrected  610 , the snapshot module  402  creates  604  a new snapshot, and the testing module  404  applies  606  a set of tests again. For example, one development team may use a go-no-go approach to evaluate the test results.  
         [0054]     In the go-no-go approach, a team leader may poll the team members once 95% of the tests are passed successfully. Each member must agree that the snapshot is acceptable for shipment before the snapshot is transmitted to a user. If the snapshot evaluation determines  608  that the snapshot is suitable for delivery, the documentation module  408  then documents  612  attributes of the snapshot. Snapshot attributes may include documentation of known defects, defect corrections, added features and functions, defect tracking numbers, installation instructions, version number, application notes, work-arounds, and/or other information deemed useful to the user.  
         [0055]     The delivery module  406  then delivers  614  the snapshot to a user as discussed in the method  500  of  FIG. 5  and the method  200  of  FIG. 2 . The snapshot is then installed  616  on a mainframe computer.  
         [0056]     In one embodiment, a tracking module  410  may track  618  and report defects in the snapshot and the method  600  ends  620 . Reported defects are corrected  610  as discussed above. Tracking and reporting  618  of defect may take many forms. In one embodiment, the tracking module  410  is used and accessible to the software developers and engineers. In another embodiment, the tracking module  410  is used and accessible to the snapshot users. In yet another embodiment, both the software developers and snapshot users access and use the tracking module  410 . The tracking module  410  may be embodied by a software application, hardware, or a combination of the two. The tracking module  410  may be available to a user in a client-server environment or through a website. One skilled in the art will recognize other embodiments to track snapshot defects.  
         [0057]     The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.