Week 1

Day 2

Guidelines for
Developing an Oracle
Application

The effort to develop a new Oracle application depends on many factors. Many excellent books have been written on the general topic of application development. In this lesson, you examine some of the considerations that come into play during the development of an Oracle database application.

Lessons Learned

The sad reality of applications development is that the failure rate is surprisingly high; the majority of new applications do not go into production. As an applications developer, it is important for you to understand why this is the case and what its implications are on the development process. If you religiously follow the suggestions in this lesson—or any other source—there is no guarantee that you will be successful in implementing the new application. If you haven't already discovered it, there is no silver bullet when it comes to software development!

In an ideal world, the steps for developing a new application consist of:

• Gathering requirements
• Designing the application
• Building the application
• Testing the application
• Deploying the application
• Maintaining the application

In reality, these steps are rarely followed in a serial fashion. Instead, a more common approach is for the sequence to be repeated several times, with the application getting closer and closer to implementing the "true requirements" (see Figure 2.1).

Let's delve into each of these steps a bit further.

Figure 2.1.
Application develop-
ment cycle.

Gathering Requirements

The starting point for developing a new application is the task of gathering requirements. The task of defining the requirements of a new application is assumed to be necessary, straightforward, and obvious by everyone who has an influence on the new application. Gathering requirements is an art, not a science, and there are pitfalls every step of the way:

• Human communication: Obtaining requirements always involves some sort of human communication—either talking, listening, reading, or writing. Because human language is imprecise, it is subject to interpretation. This interpretation applies to both others and to you, the application developer.

• Politics: The development of a new application is fraught with political danger. One set of users may specify a requirement, whereas a different set of users may demand a conflicting requirement. It is up to you to work with these individuals and determine who is correct, whose voice matters, and who really needs to be satisfied at the end of the project. The risk of an application development project is proportional to the number of organizations that are involved in its development (see Figure 2.2).

• Constant change: Very often, you'll be developing a new application in an environment where the requirements are changing. If you're lucky, someone will even remember to tell you what is changing, the reasons for the change, and the implications on the existing requirements. You'll find it quite challenging to come up with an architecture that will meet these changing requirements.

Figure 2.2.
Risk and its relation-
ship to organizational
complexity.

You'll want to gather several types of requirements for your application:

• Functional requirements: These describe both high-level and low-level requirements that are to be satisfied by the application. An example of a high-level requirement might be "The Flugle College Information System shall allow instructors to assign grades to their students."

• Data requirements: These requirements describe the information that must be managed by the application. These requirements are crucial to the development of a logical data model that helps implement the functional requirements. For instance, a data requirement could be "The Flugle College Information System shall maintain information about the courses that are offered by each department."

• Performance requirements: These requirements describe the performance that the entire system, including the application, must satisfy. For example, a performance requirement could be "The Flugle College Information System shall be capable of supporting 120 simultaneous users while providing a response time of less that two seconds to register a student for a class."

There are many ways to keep track of requirements. Of course, you can take detailed notes. You also can build a requirements database and generate documentation from that. Or you could use components in Designer/2000 or other Computer Aided Software Engineering (CASE) tools. However, the method that you use to gather and document requirements is a function of several items:

• Application complexity: Is the application being developed for a small group of users or for a major division of a large organization?

• Budget: Is the application being funded on a shoestring, or have vice presidents signed off on the funding for this major task?

• Number of people assigned to the development of the application: Are you the only full-time person working to develop the application (with others providing time on an as-needed basis), or are there dozens of people who are involved in the development of the application?

• Visibility: Is the application to be developed unknown outside a small team, or are upper-level managers going to be promoted or asked to resign based on the successful implementation of the application?

The answers to these questions will determine how structured you should be in gathering requirements and reviewing your understanding of the requirements with the stakeholders—end users, managers, and other developers. If your project has straightforward requirements, a modest budget, and a small staff, you may want to adapt an informal methodology for gathering and reviewing requirements: you still will want to document everything but without a formal review and signoff process. However, if your project has complex requirements, a significant budget, and a large staff, you should anticipate a formal process for requirements gathering, analysis, review, and signoff; if you don't see such a process in place, you may be witnessing a failure it its initial stage.

Designing and Building the Application

Someone once said that when designing a system, ten thousand decisions are made and rarely recorded. There are many major aspects to designing an application:

• Develop a logical data model: If there is no existing database for the application, a logical data model will be needed; you'll learn more about this on Day 3, "Logical Database Design." This is probably the most important step in the design process. No matter how small the project, you really should try to use an entity-relationship modeling tool such as the Entity-Relationship Diagrammer in Designer/2000, the Oracle Database Designer, or LogicWorks' ERwin; on Day 19, "An Overview of Oracle Database Security and Tuning," you'll see how Database Designer can be used to construct a logical data model. Such tools will enable you to graphically construct a model of the information to be managed by the application. The big advantage of these tools is that they will generate an Oracle database from the model. They also provide a central repository for documenting the data that the application will manipulate.

• Choose development tools: Unless this decision is made for you, you'll need to look at the client machines that need to be supported (for example, Windows, Mac, or Motif) and the preferences of other developers. Of course, you also should factor in your experience with various development tools. You also need to consider the installed base of users when selecting development tools; a superior product