[1 ]   
A discussion of the processes and issues of developing software with a multi-person or multi-location development team. Covers defining the development process from specifications though documentation, development, testing, delivery and maintenance. Drilldown into several tools, including Anomaly Tracking System and Visual SourceSafe.
"After more than 30 years of programming, we ought to know that the design of complex software is inherently difficult."
I, like many xBase developers, started out my career in a more honest profession. I was the type of person knew how to change the printer ribbon, and wasn’t afraid to open up a laser printer with a paper jam. Before I knew it, I was drafted to write batch files, then spreadsheet macros, then quick-and-dirty data routines to print a set of address labels. Now, ten years later, I'm trying to manage team development of multi-user, multi-location applications used in real-time to steer the course of a business. What a long, strange trip it's been…
The PC Revolution occurred with the introduction of cheap processing power into the office, combined with the growing dissatisfaction with the glacial response times of mainframe shops to the needs of a business. Over time, dependence on PC-based systems has grown with the increasing capabilities of those systems to reflect the company’s business, but without many of the checks and balances of the larger scale IS systems.
"Software engineering" in many shops, is an insult to the true engineers of our world.
Over the years, many successful PC shops have adopted the practices of their big brother mainframe shops, with the results that sometimes the PC shop ends up as unresponsive as the "glass house." The goal of this discussion is to let you know that it is possible to introduce the reliability and repeatability of successes without a complete slowdown, by synthesizing the best practices of large-scale shops with the new tools of the 90s. It is urgent that we bring the reliability and robustness of our applications up to the level of solid mainframe applications without bogging down the development processes in unneeded bureaucracy.
There are no new problems under the sun, just new people encountering the same old problems, disguised in new terminology.
Study the new tools becoming available for better planning and managing a project, consider adding new tools gradually to the capabilities of your group.
Source code control can be a very useful tool to the solo developer as well as a key tool for multiple-developer teams. For the solo developer, source code control provides backup facilities and the ability to perform a "grand undo" as well as retrieve early builds or versions. With a multiple-developer team, source code control can ensure that all members of the team work with the latest revision of source code, protect the members of the team from inadvertently overwriting each others work, and provides a simple method to keep track of multiple releases of the software to the same or different clients.
Source code control programs have been around for quite some time but, like difficult backup programs, programs that prove too hard to use are too easy to avoid. With the increasing complexity of projects and the improved accessibility of these products, they are tools are worth the effort to learn. Integration of source code control directly into the development environment is a relatively recent feature that makes these programs easier to use.
Bear in mind that Visual SourceSafe, or any other source code control program, is its own product and you must learn its terminology and operations to get the greatest benefit from it. While many operations can easily be performed from within the FoxPro interface, you should become familiar with the less frequently needed maintenance functions that may only be available within the program itself.
|CAUTION: VS97 SP-2 causes "Invalid Page Faults" in VFP if using integrated SourceSafe projects! Locate SSCCC.DLL (in the Win32 subdirectory of VSS). Remove the SSCCC.DLL from the SP-2 installation (Build 2220) and replace it with the original from the VS 97 disks (Build 2218).|
After installation, the developer who creates a project selects "Add Project to Source Control" if the Tools/Options are not set to do this automatically. All other developers can now access the project by selecting "Join Source Control Project…" from their File menu.
Each developer maintains their own copy of the shared project, and each has a complete copy of all of the source code. By default, all of the source code is flagged read-only to prevent inadvertent code changes. After checking out an individual file, additions and modifications to the source code are made by each developer on their local machine. When the changes have been tested and are ready to be shared with the rest of the development team, the developer chooses "Update Project List" from the Project/Source Control menu. This option updates a text version of the project, a .PJM file, with the changes this developer has made to their local project file. When other developers choose to update the shared project list, they will see the changes made by this developer.
Source Code Control works best on text files, as differing versions of text files can be visually compared. Since FoxPro keeps a lot of its designs in table format (SCX, VCX, MNX), these files cannot be compared directly. Instead, the integrated source control creates an ASCII version of each of these files (with corresponding SCA, VCA and MNA extensions) so that changes can be "diffed." The SCCTEXT.PRG program is used to create and interpret these ASCII files; this file can be modified to suit your needs.
Figure 1: Source Code Control using VFP's Project Manager enforces coordination between developers
Figure 2: Administrator option for multiple checkouts must be turned on.
[1 ]