Access Database Programming
Upgrading Access Projects
 The current Access database
computer system may not be able to cope with the growing administrative requirements
of a company. The inadequacies may relate to increased volumes handled, additional
functional requirements or new company directions.
A decision then needs to be made on how to improve the software to achieve the required
quality and functionality. The choice is between two development options –
Evolutionary development or Revolutionary development.
Here is a brief summary of the differences between the two options:
Development by Evolution
This is the low risk, but not glamorous, choice. It involves adding small and frequent
improvements to an existing system. It is a reliable and systematic means to improve
an existing system. It could be thought of as an extension of the maintenance mode,
but goes further than just fixing critical bugs.
The Benefits are:
- It is a low risk strategy.
- The cost of the strategy can be tightly controlled.
- It is always of value to build on proven work of the past.
The downside is:
- The system may be slow in showing results.
- The enhancements may be hard to implement due to the existing code.
- There may be technical limitations in the software that a step-by-step approach
cannot resolve.
Development by Revolution
This is a high risk strategy – the failure rate of new projects is very high.
So there should be sufficient incentive to go down this path. It involves completely
rewriting the system using new and promising, but usually unproven technology.
The benefits are:
- Improving on antiquated coding techniques.
- Greater awareness of user requirements due to the known inadequacies of the existing
system.
- New administration and management functionality.
- Incorporating the latest techniques and software technology.
The downside is:
- The old system and the new system must run in parallel until the new system is proven
to be at least equal to the old system.
- There needs to be multiple conversions of the records of the old system to the new
system. This is needed to allow the users to check the consistency between the two
systems at each new release.
- Extracting the business rules from the code and the user interface may be near impossible.
- The new system may be unstable for a lengthy period.
- There may be resistance from the users.
- Success depends upon the quality of the new development team. If they are lacking
in experience or foresight or competence, the project is doomed from the start.
- Despite all the advances in system design and development tools, the complexity
of new systems remains. The success rate for new projects is low.
- An unsuccessful project could have a negative impact on the administration processes.
- An unsuccessful project could affect the viability of the company.
- If development is started from scratch, a valuable and costly asset will be thrown
away.
Gathering Application Requirements
In most cases the original specifications are nonexistent, as are their authors.
Where the original specifications are available, they will almost always be out
of date, with the successive changes over the years. If the analyst is unable to
extract information from the old system code (and this is usually the case), there
is nothing left but to try understand the processes from low level users and vague
managers.
To develop a software package, the analyst must identify the needs of the company.
This is difficult as the analyst is unlikely to understand fully the company's work
practices, or the terminology of the company. There is also the possibility that
management and the users do not know exactly what is required.
Extending the life of the system
Many books have been written about the development of new computer projects, so
I will stick to ideas to improve existing software.
The Evolutionary improvements should:
- Improve the quality of the system, by adding error handling routines to each and
every procedure. When an error is trapped, all possible clues should be extracted
to help identify and solve the problem.
- Make the system more user-friendly.
- Create reusable modules for repeatedly duplicated code
- Simplify convoluted and spaghetti code
- Gradually replace system functionality with newer technology
- Use refactoring of the code to extend the system life span. This will improve the
readability of the code, remove dead code, make the code easier to comprehend and
maintain.
If the decision is made to try this option, and it turns out to be not feasible
– little will have been lost.
Getting Advice
Many programmers and consultants will go for the system rewrite option with new
software and new technology. It is more fulfilling and improves their future prospects
– it is in their vested interests to go for this option.
So beware!
A word on upgrading Microsoft Access software
Newly released Microsoft Access software soon becomes dominant. It is then virtually
impossible to purchase the previous version – and a database system could
be using obsolete software.
There is always good reason to use the latest Microsoft software, not only because
of the additional functionality, but also to avoid security issues and problems
with procedures that no longer work on newer Windows operating systems. There is
also good reason not to use the latest software too soon. Best to wait until a few
service packs have been released to ensure a problem free upgrade.
Ignoring successive new Microsoft Access Database updates is false economy. Sooner
or later your Microsoft Access application will have to be replaced or the Microsoft
software upgraded. Either way, this will be costly in the long run.
|