Datasheet

Designing Applications

The Development Process

There are many skills involved in the development and delivery of successful Microsoft Access

2002 applications. The database designers need to be able to understand the principles of

relational database design, so that they can design the tables that will hold the data and the

relationships between those tables. The application developers need to have a feel for the

graphical user interface (GUI) design, so that the forms they design for users to interact with

will be intuitive and easy to use. They will also need to understand both SQL (Structured Query

Language) and VBA so that they can write queries and procedures that not only return the

correct data or perform the required task, but also do so quickly and efficiently.

There are other less technical (but no less complex) skills to master. Analysts need to be able to

understand the business requirements of the users for whom the application is being designed,

and to translate these requirements into a design specification from which the developers can

work. Technical documenters need to be able to articulate how the application works, to

anticipate confusions that users might experience and to clearly express their thoughts in

documentation that is both accessible and informative. Test engineers need to be rigorous in

their approach, perhaps using formal methodologies to check for errors, and must not take

anything for granted when evaluating the application. Last, but certainly not least, project

managers need to know how to monitor progress and track resource usage to ensure that the

application is delivered on time and within budget.

Sometimes, if the application being developed is large-scale or complex, then there will be

many different people involved in the application development lifecycle. Some will be

responsible purely for analysis or design, others will work solely on designing queries or

developing forms, and yet others will be responsible for other tasks, such as migrating legacy

data into the Access database or producing user documentation. But at other times, particularly

if the application is less complex, or if resources (such as money or people) are scarcer, then it is

not uncommon for many of these tasks to be undertaken by individuals. Indeed, in many

situations, a single person can be responsible for the entire analysis and development process.

Irrespective of the number of people involved, or the development methodology employed, the

development lifecycle for an Access application will typically involve the following steps:

Analysis

Design Coding Testing Documentation Acceptance Review

In practice, however, these steps do not rigidly follow one after another. There can be

significant overlaps and the project can iterate through some of these steps before progressing

on to others. It is beyond the scope of this book to enter into a detailed discussion of different

project lifecycle plans. However, it is undoubtedly true that the speed with which Access forms

and reports can be produced makes Access an excellent tool for using in a more iterative

lifecycle model. In such a situation, the lifecycle would look more like this: