Page 24
with a smaller installed base of users is a less attractive choice than a good product with a very large installed base of users. If you have decided to use a tool that you haven't used before, be sure that you allocate enough time to become thoroughly proficient with it; you don't want to discover its shortcomings halfway through a project.
Implement the functionality that the users need: In general, it's better to schedule more releases of the application to the users rather than fewer. Each release will incorporate a little more of the functionality that the users are expecting. Each release will give the users an opportunity to provide feedback on what you've given them; it also will give you the opportunity to incorporate their feedback in the next release. Through this process, the end users "buy into" the project; over time, they become stakeholders. This is crucial; if the users don't accept the final delivery of the application, it is doomed to failure.
Make use of reusable components: When feasible, try to design a set of reusable components. Needless to say, the degree of reusability will depend on the development tools that you are using. If the tools are not object-oriented, the reusable components will consist of form and report templates, libraries, and header files. If the tools support object-oriented development, the reusable components will consist of ancestor classes from which a working application can be constructed. During Day 18, "Developing an Application with Oracle Power Objects," you'll see how you can create classes in Power Objects to simplify the maintenance of an application. Although reusability is a lofty goal, be judicious in how much time and energy you invest.
Use a configuration management (CM) tool: No matter how modest your application development effort is, you should plan on using some form of configuration management. At a minimum, you will want to keep a backup, either on tape or removable disk, of each release of your application. For medium-sized or large projects, this is not sufficient; plan on using a multiuser CM tool that supports version control. The items that you should keep under CM include: source-code files, SQL scripts for creating and populating the Oracle database, PL/SQL source code, design documents, test data sets, training material, and text files for producing online help.
Identify user roles and privileges: In designing your application, identify the major roles that users will assume when using the system. You should implement these roles at two levels: at the database level and at the application level—both are important. You should specify the privileges—create, read, update, and delete (often referred to as CRUD)—that should be granted to each role for each database table, view, or other object. Depending on the application development tool you use, you should be able to associate a user's login to his or her role, and in turn associate that role with the menu items that should be enabled for that role.
Page 25
Remain platform-independent where possible: There are two platforms you need to consider in the design phase of the project: the server and the client. On the server side, try to use PL/SQL wherever possible for implementing application logic; this will minimize the work needed to port the application from one server platform (such as Windows NT) to another server platform (such as Solaris). On the client side, determine what features specific to the operating system (OS) you must provide. If you do incorporate OS-specific features in the application (such as OLE), the application will not be able to provide those features on all client platforms (such as Mac and Motif). As a result, you may make some users happier than others.
Provide a consistent user interface: Each category of screens and reports should have a similar appearance. For example, all data-entry screens should have the same set of buttons, located in the same relative position, that perform the same function. The same fonts, font sizes, and color schemes should be used on your forms. If a gray background is used to indicate that a field is read-only on one screen, all read-only fields should have a gray background.
Incorporate a diagnostic capability in the application: If possible, a diagnostic capability should be built into your application. This capability should allow the application to display or record (or both) its execution. This record can include the name of each module or function that is executing, a timestamp, significant events, error codes, and other items that can assist you in tracking down problems during the development or deployment phases of the project. For maximum flexibility, the diagnostic capability should be configurable at runtime (for example, in an INI file or the Windows Registry).
You should plan to test the application at every stage of development. It's important to define what is meant by testing. Perhaps it's stretching the term, but testing can be considered to include the following:
Page 26
In addition to the previous items, you need to plan for specific types of tests:
If you are building an application that needs to run on several different client machines (such as Windows 3.11, Windows 95, and Mac), be sure that someone makes these computers available to you during testing, deployment, and maintenance. Otherwise, you will have a very hard time reproducing, diagnosing, and fixing reported bugs. Also, be sure that these machines are representative of the users' machines, in terms of processor speed, memory, and available disk space.
There are several issues that you'll need to consider during deployment:
Installing the application: If you're installing the application for a small group of users who are geographically close, you may have the luxury of installing the software yourself. If there are many users or they are geographically scattered, you must plan on a more automated way to install the software. There are several choices. You can produce a set of installation disks (or a CD-ROM) that automates the installation. You can use a file server, accessible by all users for the installation. Or, you could establish a Web site from which the users can download the software and follow a set of directions. In all cases, the installation will consist of two major tasks. The first is to create a directory on the user's machine, copy all the necessary files to that directory, and configure the environment. The second is to install and configure the SQL*Net product, assuming that it isn't already installed.
Training the users: Somehow, time must be allocated for training the end-users in the use of the application. The training can be instructor-led or computer-based (CBT). Some managers may argue that the end-users don't have time available for formal training. However, one way or another, the users will need time to learn to use the software.
Providing online help: After receiving training, users still will have questions about the use of the software. An effective way of providing answers to these questions is by supplying a help file that works with the application program to provide context-sensitive help.
You've come a long way. You've gathered requirements, designed, built, tested, and deployed the application—now what? Expect feedback from the users—both positive (hopefully) and