لطفا منتظر باشید ...
How Do I Get Started Developing an Access Application?
Many developers believe that because Access is such a rapid application development environment, there's absolutely no need for system analysis or design when creating an application. I couldn't disagree more. As mentioned earlier in this chapter, Access applications are deceptively easy to create, but without proper planning, they can become a disaster.
Task Analysis
The first step in the development process is task analysis , or considering each and every process that occurs during the user's workdaya cumbersome but necessary task. When I first started working for a large corporation as a mainframe programmer, I was required to carefully follow a task analysis checklist. I had to find out what each user of the system did to complete his or her daily tasks, document each procedure, determine the flow of each task to the next, relate each task of each user to her other tasks as well as to the tasks of every other user of the system, and tie each task to corporate objectives. In this day and age of rapid application development and changing technology, task analysis in the development process seems to have gone out the window. I maintain that if you don't take the required care to complete this process at least at some level, you will have to rewrite large parts of the application.
Data Analysis and Design
After you have analyzed and documented all the tasks involved in the system, you're ready to work on the data analysis and design phase of your application. In this phase, you must identify each piece of information needed to complete each task. You must assign these data elements to subjects, and each subject will become a separate table in your database. For example, a subject might be a client; every data element relating to that clientthe name, address, phone, credit limit, and any other pertinent informationwould become fields within the client table.You should determine the following for each data element:
- Appropriate data type
- Required size
- Validation rules
You should also determine whether you will allow the user to update each data element and whether it's entered or calculated; then you can figure out whether you have properly normalized your table structures.
Normalization Made Easy
Normalization is a fancy term for the process of testing your table design against a series of rules that ensure that your application will operate as efficiently as possible. These rules are based on set theory and were originally proposed by Dr. E. F. Codd. Although you could spend years studying normalization, its main objective is an application that runs efficiently with as little data manipulation and coding as possible. Chapter 3 covers normalization and database design in detail. For now, here are six of the basic normalization rules:
Take a look at an example. The datasheet shown in Figure 1.16 is an example of a table that hasn't been normalized. Notice that the CustInfo field is repeated for each order, so if the customer address changes, it has to be changed in every order assigned to that customer. In other words, the CustInfo field is not atomic. If you want to sort by city, you're out of luck, because the city is in the middle of the CustInfo field. If the name of an inventory item changes, you need to make the change in every record where that inventory item was ordered. Probably the worst problem in this example involves items ordered. With this design, you must create four fields for each item the customer orders: name, supplier, quantity, and price. This design would make it extremely difficult to build sales reports and other reports your users need to effectively run the business.
Figure 1.16. This table hasn't been normalized.
Figure 1.17 shows the same data normalized. Notice that I've broken it out into several different tables: tblCustomers, tblOrders, tblOrderDetails, and tblSuppliers. The tblCustomers table contains data that relates only to a specific customer.
Figure 1.17. The data has been normalized into four separate tables.
I have uniquely identified each record by a contrived CustID field, which I use to relate the orders table, tblOrders, to tblCustomers. The tblOrders table contains only information that applies to the entire order, rather than to a particular item that the customer ordered. This table contains the CustID of the customer who placed the order and the date of the order, and I've related it to the tblOrderDetails table based on the OrderID. The tblOrderDetails table holds information about each item ordered for a particular OrderID.There's no limit to the potential number of items that the user can place on an order. The user can add as many items to the order as needed, simply by adding more records to the tblOrderDetails table. Finally, I placed the supplier information in a separate table, tblSuppliers, so that if any of the supplier information changes, the user has to change it in only one place.
Prototyping
Although the task analysis and data analysis phases of application development haven't changed much since the days of mainframes, the prototyping phase has changed. In working with mainframes or DOS-based languages, it was important to develop detailed specifications for each screen and report. I remember requiring users to sign off on every screen and report. Even a change such as moving a field on a screen meant a change order and approval for additional hours. After the user signed off on the screen and report specifications, the programmers would go off for days and work arduously to develop each screen and report. They would return to the user after many months only to hear that everything was wrong. This meant back to the drawing board for the developer and many additional hours before the user could once again review the application.The process is quite different now. As soon as you have outlined the tasks and the data analysis is complete, the developer can design the tables and establish relationships among them. The form and report prototype process can then begin. Rather than the developer going off for weeks or months before having further interaction with the user, the developer needs only a few days, using the Access wizards to quickly develop form prototypes.
Testing
As far as testing goes, you just can't do enough. I recommend that, if your application is going to be run in Windows 98, Windows NT, Windows 2000, and Windows XP, you test in all environments. I also suggest you test your application extensively on the lowest common denominator piece of hardwarethe application might run great on your machine, but show unacceptable performance on your users' machines.It usually helps to test your application both in pieces and as an integrated application. Recruit several people to test your application and make sure they range from the most savvy of users to the least computer-adept person you can find. These different types of users will probably find completely different sets of problems. Most importantly, make sure you're not the only tester of your application, because you're the least likely person to find errors in your own programs.
Implementation
Your application is finally ready to go out into the world, or at least you hope so! Distribute your application to a subset of your users and make sure they know they're performing the test case. Make them feel honored to participate as the first users of the system, but warn them that problems might occur, and it's their responsibility to make you aware of them. If you distribute your application on a wide-scale basis and it doesn't operate exactly as it should, it will be difficult to regain the confidence of your users. That's why it is so important to roll out your application slowly.
Maintenance
Because Access is such a rapid application-development environment, the maintenance period tends to be much more extended than the one for a mainframe or DOS-based application. Users are much more demanding; the more you give them, the more they want. For a consultant, this is great. Just don't get into a fixed-bid situationbecause of the scope of the application changing, you could very well end up on the losing end of that deal.There are three categories of maintenance activities :
bug fixes, specification changes, and frills. You need to handle bug fixes as quickly as possible. The implications of specification changes need to be clearly explained to the user, including the time and cost involved in making the requested changes. As far as frills go, try to involve the users as much as possible in adding frills by teaching them how to enhance forms and reports and by making the application as flexible and user-defined as possible. Of course, the final objective of any application is a happy group of productive users.
