Access Projects / Software Development - How long can they take to complete?

Could it be possible that my approach is too structured and some Projects are indeed never done in a structured way?

Lot of ground there to cover and there is no right or wrong answer.   As always, it would depend on the requirements.

Project for a small business?   Never going to be structured.  Project for a Mars lander?  Going to be VERY structured.  I would say though that in general for the types of things Access is used for, most would be non-structured vs structured.   That's not to say it can't be a quality piece of software, but things will not be documented to the nth degree, and probably would not even be fully spec'd out.

 Quite often in the business world, things change at a very fast pace, which is why development methodologies such as agile came about.  But that has it's downfalls to.   Numerous Incremental changes are not always a good thing.

As far as time, without knowing all the details, it's very hard to say.   I've seen apps with few forms and tables, but have complex processing and take lots of time, or have a lot of forms and reports, but it's all very simple and straight forward and can be achieved with the built-in features in Access in a short amount of time.

 I would add that you generally will find that things take a lot less time in Access than in other tools (say .Net) if you let Access do the work.

Jim.

But there is nothing wrong with having it structured?
My idea is that if someone else needs to make changes to the database, they will find it easier if documentation is available.
Furthermore, if I have a structure, I know which requirements to implement.

I have a feeling that creating the database will be the easiest part.
The more difficult part will be to import data from the previous DB which was simply not good (the data was not normalised).

Hi John

Database programming is not an issue. But before I even start, should I not know what is required - hence the software elicitation process?
Otherwise, how can you create a DB or software if you don't know what the customer wants?

This is a mini-project - and good practice for me.

Creating the database should and ought to be the hardest part...you need to normalize the data and have the table structure "ready" to accommodate future features...an application is easy to change even its base platform e.g. from Access to .NET...but changing the data (of course we are talking on somewhat enterprise level) is usually next to impossible and this starts with the proper keys,indexes and of course field names

Yes, I am aware of normalisation and I will stop at the 3rd normal Level.
I am not concerned about databases - I am more concerned about my approach:
software eliciation - functional requirements/use cases - implementation - testing

Well you are thinking too academic...just think as the end user that is going to use your application and you should be good to go...as Jim said you are ΝΟΤ building an application for taking man to Mars but an application that is going to be used by some end users..
Or to put it in other words
software elicitation --> talk/work with the users to "see" what they have right now,what they need,what they might don't know,improvements.
functional requirements/use cases --> see above along with maybe your current development environment...
implementation/testing --> well just implement what you have gather from the previous.

Sadly, we cannot say how long this should take:  Aside from not knowing the scope of the project, we have no way of knowing your abilities.

In Access, I'm sure Jim could deliver a system faster than I could because my VBA and Access is old and rusty since I haven't used it for a few years.

While what you learn in school is very valuable, it does have flaws.  There are times where things in the real world just don't line up to academics.

For a small project I have the feeling that if you pursue a full development lifecycle, it might backfire.  I mean how long do you need to spend talking to users and getting sign-off on use cases for a recipe database?

You also run the risk of:  https://en.wikipedia.org/wiki/Analysis_paralysis

I recently moved to a project using Agile and we are starting to move into DevOps.  It is an interesting shift from what I've been used to for years.

For small projects I've always liked RAD:  Rapid Application Development
https://www.enterpriseinnovation.net/article/which-do-you-need-rapid-application-development-vs-agile-977455002

This falls in line with John's advice:  I would probably start with a simple UI mockup and get feedback from the users.

Remember to design the interface assuming it will be what YOU, the developer, will be using 10 hours a day every day for the next 10 years!

I've seen many "functional" interfaces that really weren't all that "usable".  Why?  The developers never had to use it on an hourly basis like the users.

Also:
NEVER assume the users know what they want.  They think they do but it is rare they actually do.  Many times they also may not know what is even possible.  They have grown accustomed to what they have been doing.

In talking with them remember to ask:  What if?  ex:  What if we made this a dropdown and moved it over here?

I will agree that the ETL and data cleaning of the dirty data will probably be a large piece of the project.

Well here is what I have done:


a) I had a look at the previous system
b) I sat down with the people involved and asked them what they do, how they used the previous system and let them talk. Then I asked them more specific questions.
c) I described the system Domain with a class diagram so that I know what the people involved do
d) I created the requirements (three pages)

I completely forgot about the RAD process so I will create a mockup and show it to people.

I have developed databases with Access before and I have already studied database design (half a year), so I feel comfortable with databases. I have worked with VBA before and the algorithms module I studied taught me how to create an efficient algorithm/methods. The concept of classes in VBA is new to me, but I do not think that I will need them as, already mentiond: Access can do quite a lot on its own. Especially the reporting tool is excellent.

I was just curious to hear from people who have created similar projects before whether my approach was/is acceptable.

I might not have done all the steps you have already done but they probably weren't wasted efforts.

Please let us know how things went!!!

Was my approach too academic? I think so - because I was taught this approach at university this semester. Although I have spent a lot of time talking to people and analysing the existing DB (which doesn't work anymore because of no normalisation), I do not think it was wasted effort. I guess it is difficult at the beginning to bridge the dichotomy between theory and practice; I just need some more experience.

Now that I have the requirements, I will go the RAD approach, and as a start create some mockups.

Thank you so much for your valuable feedback!

Massimo