|
|
One critical aspect of construction planning is the definition, set-up, implementation, and control of the overall system development environment. This includes the various programming, testing, staging, and production libraries which will be utilized. It also includes the formal procedures which will be implemented for program version tracking, program migration, database updates, and source code back-ups.
The key consideration for developing an effective development environment is to go easy on the "red tape", yet put enough controls in place to ensure the integrity of the evolving system. This balance is a vital contributor to both the increased forward momentum, and the decreased stress level, experienced by the development team. This is especially true during the high productivity "crunch periods", when quick updates and straight forward staging is important.
Anther benefit of careful environment planning is a feeling of reassurance knowing that every completed work product will have its "place". This avoids the situation of having bits and pieces of source code, compiled results, and database definitions scattered everywhere, rather than residing in a clearly identified repository. Many companies have spend many years institutionalizing the libraries and procedures used for systems development (especially in the mainframe environment). But as many more technical platforms are employed, including the increasing use of PC based, stand-alone programming development workstations, these infrastructure decisions are needing to be more and more frequently reassessed.
By far the technical environment which is providing the most new infrastructure challenges for system builders is the rapidly evolving client/server environment. In this arena, not only do the library and procedural issues need consideration, but also the program versioning and migration issues need attention, especially across multiple platforms and multiple workstations. No matter which technical environment is chosen, the key point to remember is to think through a practical infrastructure approach which will protect the system investment, and then stick to it!
Listed below is a "first-cut" list of standardized libraries for consideration:
Source Code
Undoubtedly, the single most important library in which the programmers will be working is the one containing the evolving source code. This is where the time is being invested throughout this phase. The primary consideration should be to develop an approach to maintaining this asset which is organized, accessible, and understandable. Many organizations insist that completed program source code eventually end up in a centralized library or directory which provides back-up, check-out, and versioning capabilities. Many commercial products exist on the market which provide these safeguards. The team must either use these available offerings, or develop an effective approach to code management on its own. In either case, these up front decisions are vital, especially if the programmers are developing their programs on a stand-alone PC workstations.
Common Routines
Many companies have over the years have developed a set of standardized pre-coded routines which are intended to be utilized by existing as well as new programs. These are generally known as "include libraries", and they are often stored in a different library or directory than the source programs which reference them. The team should decide whether or not it will also adopt this approach, and decide if the existing routines will be utilized.
Frameworks/Classes
The advent of object-oriented programming languages has brought an even more disciplined approach to sharing program modules or classes. Many objected-oriented compilers are delivered with an extensive library of standardized program classes which are fully tested and documented. In addition, third-party class libraries are also available to beef-up the team's current application building capabilities. Both of these sources of prebuilt classes provide the fundamental program building blocks for creating even more complex, efficient, and cost effective applications.
If the team plans to use an object-oriented language, consideration should be given to assigning someone to be a "class librarian". This person should be charged with organizing the existing class library, and he or she should also categorize, document, and add any team developed classes into the library for subsequent utilization and sharing.
Application Programs
A very common practice is to develop a series of staging libraries in which to place the compiled, executable programs.
Development Library
This is the library where the day to day programming activities take place. It contains the executable versions of each of the programs which are still considered to be "works in progress".
System Test Library
This library contains the executable versions of the programs which are ready for more formalized testing. Having a separate staging area for these programs facilitates the use of an independent test team whose activities will not interfere with efforts of the developers.
Production Library
This library is the exclusive domain of the business clients. The finalized, tested versions of each program are migrated to this library for utilization by the business clients to meet their specified business requirements. This library or directory is the most closely protected since it directly impacts the results of the business processing.
Job Control Statements
Equally important, a place must also be identified for the completed batch jobs (for those mainframers still out there!). For this library or directory, again it is probably a good idea to put into place the same types of back-up and versioning control safeguards as those discussed earlier for the program source code.
Database Definitions
Another important area of concern is the location of the database definition source code. Fortunately, many commercial database products define this location by default for the team. But for those which do not, the same care and consideration should be applied to the maintenance and location of the database definitions as was considered for the program source code. In addition, decisions will need to be made as to who will have access to this library. In many companies, the finalized database definitions are only available to database administrators.
