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

My issue or question is about software development in genereal.

I am currently studying software development and will be studying software engineering shortly. At the same time I am doing an internship have been asked to create an employee database with Microsoft Access. As I am developing this by myself, I will doing it the traditional way: software elicitation/Analysis/requirements/implementation - the way taught at university.

This morning, I was asked by my boss how long it will take me to complete this project. As I am doing it for the first time in such a structured way, I would appreciate it if I could get some feedback from you guys how long it can take to complete a smaller Access project -  either each phase of development (following IEEE format) or for the entire project.

Although my boss has worked in (big) projects, they apparently never worked in structured way: not agile, spiral, waterfall etc.. Although the product works, I thought that not only is important to deliver a quality product, but also add quality how I work.

Could it be possible that my approach is too structured and some Projects are indeed never done in a structured way?
Or that what is taught in software development/engineering is not applied in real projects - in other words too theoretical?

Thanks for your feedback

Massimo ScolaInternshipAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
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.

John TsioumprisSoftware & Systems EngineerCommented:
Well in short theory and practice and 2 different things but one can't do without the other....
Start with a simple mockup of what your application should do and just construct something minimal that it works...put your theory in designing the mockup but just don't waste a ton of time in designing and applying all the known methods...then its time for implementation ...implement it so that for start it works...nothing fancy..nothing "containing" all the programming guide lines and all the "right" things to do...but  above all it should be working...then its once more time to examine your design and  try and implement all the "goodies"...its much easier to refactor and enhance an application than to try to design the perfect application and then try to implement it.
One thing that should be done at the very beginning is to have a solid database about normalization and good database design along with good programming techniques (e.g. proper variable naming)...focus on these first probably with mini projects and then move to a more advanced one...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Massimo ScolaInternshipAuthor Commented:
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).
Get a highly available system for cyber protection

The Acronis SDI Appliance is a new plug-n-play solution with pre-configured Acronis Software-Defined Infrastructure software that gives service providers and enterprises ready access to a fault-tolerant system, which combines universal storage and high-performance virtualization.

Massimo ScolaInternshipAuthor Commented:
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.
John TsioumprisSoftware & Systems EngineerCommented:
Creating the database should and ought to be the hardest need to normalize the data and have the table structure "ready" to accommodate future 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
Massimo ScolaInternshipAuthor Commented:
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
John TsioumprisSoftware & Systems EngineerCommented:
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 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.
slightwv (䄆 Netminder) Commented:
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:

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

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.

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.
Massimo ScolaInternshipAuthor Commented:
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.
slightwv (䄆 Netminder) Commented:
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!!!
Massimo ScolaInternshipAuthor Commented:
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!

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.