I think Waterfall is all but dead now, since software was never really
developed that way anyway! The interative Spiral (round-trip) model seems to
be more realistic, and to my mind, is a better fit to ISO9000:2000 and CMM,
than other models. Certainly prototyping works well for Access projects.
I think the same requirements/information gathering and analysis
methodologies can be applied to Access projects, because you have the same
issues. The problem domain remains the same, and you still have to conduct
preliminary and detailed designs, although smaller projects allow detailed
design to be executed during development.
I think the case for requirements modelling (Use Cases/Scenarios) in Access
is largely a matter of project size and cost. For example, I won't even do a
formal Requirements Analysis for projects less than $20,000, because the
cost of the RA outweighs the cost of the project itself. Similarly,
developing Use Cases and Scenarios for such a project usually triples or
quadruples the overall project cost with no real benefit. If the project is
*that* small, it's going to be fairly simple. Of course, you can get
exceptions, and you might need to model certain parts of the solution. The
decision to model or not, is a case-by-case decision.
For larger projects, say $200,000 upwards, there is a good argument for
modelling, because of the project size, complexity, and the risks associated
with not doing an in-depth analysis. You can use a risk assessment matrix
and a cost-benefit analysis to determine whether to model or not. But I'd
say for the larger projects, the risks are such that requirements analysis
and iterative design processes are pretty much imperative.
Of course, there are cowboys who'll argue against doing this level of
analysis, but my view is that they're fooling themselves and demonstrate a
lack of professionalism. I know guys who will happily develop a $250,000
Access project without doing an RA, Risk Management Plan, or a Project Plan.
I have many case studies totalling millions of dollars wasted on changes in
the latter project stages, because of ill-defined or un-defined
requirements, risk realisation, business changes, scope creep, lack of
management support, bad technology decisions, inappropriate level of
complexity, and just plain bad design. I know of one guy who hates analysis
and planning, and avoids it like the plague. He will eagerly spend (and
charge for) 200 hours to develop a piece of functionality that, albeit
amazing and technically superior, is hardly necessary. He'll happily develop
a Rolls Royce, when all the customer wanted was a Holden. Requirements
Analysis, Risk Analysis, Cost-Benefit Analysis, and proper planning and
design is, in my view, imperative on large projects.
Having said that, traditional object modelling is mostly redundant in
Access, except for specific functional requirements, where you might be
building linked lists, collection classes or generalised/specialised
classes. This is largely due to one issue - linked tables and their
pseudo-automatic record updates.
With VB, C++, DotNet and the like, affecting database properties and data
can be easily modelled because the code has to cross the application
boundary, so to get that sort of functionality, you have to build it
yourself. But it's a very different story with Access. To affect the
database properties or data, you don't always need to cross the application
boundary. It's hard to represent much of the functionality we build into
Access applications, because all the object functionality is encapsulated in
the Access and data access objects. Additionally, the code we write into
Access applications tends to be a mix of user, business and data layer
stuff, and it doesn't make much sense to separate them out, except when we
split the database into front-end/backend, thereby creating a separate data
layer. Even then, the data layer code is contained in the frontend, plus,
you can have local frontend tables, which are a data layer that can't
necessarily be treated the same as the backend data layer.
I don't think traditional modelling techniques take Access into account.
They are supposed to be language/environment independent, but if you're
developing in Access, that independence is eliminated from the start. The
user, business and data layers are in the same physical location, and in
some cases, are indistinguishable, or are scattered throughout the user,
business and data objects. Additionally, because of the unique functional
abilities of Access (and its constraints), you know ahead of time what your
application/data environment is going to look like (functionally speaking),
so there is little benefit is traditional object modelling. In fact, I think
this type of modelling causes more problems than it solves, because it just
doesn't apply to Access.
Maybe I could have replied a little more simplistically, but at least it
gives you one more perspective.
Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html