First, it is harder to evaluate an .ACCDE since your ability to explore it is more limited than for an .ACCDB file of the same project. If you have the file only as an .ACCDE, you cannot look at anything in design mode and the module code isn't accessible either. Nor can you reverse the .ACCDE file back to the .ACCDB format. That conversion was a one-way street.
Second, your evaluation depends on (or at least, SHOULD depend on) factors we cannot answer here, so
you will have to do the examination and evaluation. Further, the way to properly carry out the evaluation is tenuous since we don't know the style of the project. We don't know what "ease of use" features you will need since they depend on the control style & method for your project.
Even your choice of words in your question leads to an issue. What does "Good" or "Very Good" mean in this context? We could talk about completeness, but if there is no accompanying design goal document, it might be impossible to define those terms. Further, if there is any complexity to the event code for the various forms, testing might become a problem because it might not be easy - or worse, not POSSIBLE - to test all scenarios that this project might encounter.
Project evaluation includes many features.
- Ease of use to include good labeling of controls and conformance to aspects of the real-world process it represents
- Well-organized forms and reports that show what was intended WHEN it was intended to be shown
- Accuracy of any and all computations
- !!!!Conformance to design specifications
- Where options exist, every branch and combination of branches are testable - and tested
- Where anything can be looked up and additions are possible to what CAN be looked up, methods exist to make it easy to augment the list being queried
- Where a sequence of actions is required, the project file must support those actions in the proper sequence. If there is a problem caused by straying from that sequence, the project must prevent deviations from that sequence in the least disruptive manner.
- The project's design must conform to the business process being "modeled" so as to present familiarity to its users.
- IF the design includes role-based behavior (i.e. restrictions on who can de particular actions) then the DB must be more carefully secured. I.e. you cannot depend on users to NOT do the WRONG thing.
These are the big-picture questions I would ask of any large- or mid-scale project.