How to make a large project? (1 Viewer)

[amorosik]

It's only of academic interest ...

Even if it were just an academic interest, the topic would still be of great value to someone who uses Access
Even a linked list or a bubble sort, are purely academic interests (unless one builds a db server or similar), but are still of great interest to understand how things work in certain fields

 

[CJ_London]

then it means that other conditions will have to be checked, such as the memory used by that single Access file during operation, or other conditions still

That was wat I said way back when.

 

[Pat Hartman]

Even if it were just an academic interest, the topic would still be of great value to someone who uses Access

This particular thread is useless since it is not based on reality. Access is infinitely expandable given that you can always make multiple FE's and have them link to each other and you can link to multiple BE's. The central advice you have been given is that YOU need to keep the project organized as it grows. The hard limit of Access is that it doesn't do web stuff efficiently so it is a desktop application or runs through Citrix or RD. The other limit is that without source control, it is very difficult to have multiple simultaneous developers for a single FE.

 

[Edgar_]

If it is not possible to use the 'number of objects' to understand the technical limit that can be contained in a single Access file, then it means that other conditions will have to be checked, such as the memory used by that single Access file during operation, or other conditions still

Testing has been mentioned multiple times. Here's what ISTQB, an authority in the subject, says about that:

1. Testing shows the presence, not the absence of defects. Testing can show that defects are present in the test object, but cannot prove that there are no defects (Buxton 1970). Testing reduces the probability of defects remaining undiscovered in the test object, but even if no defects are found, testing cannot prove test object correctness.
2. Exhaustive testing is impossible. Testing everything is not feasible except in trivial cases (Manna 1978). Rather than attempting to test exhaustively, test techniques (see chapter 4), test case prioritization (see section 5.1.5), and risk-based testing (see section 5.2), should be used to focus test efforts.
3. Early testing saves time and money. Defects that are removed early in the process will not cause subsequent defects in derived work products. The cost of quality will be reduced since fewer failures will occur later in the SDLC (Boehm 1981). To find defects early, both static testing (see chapter 3) and dynamic testing (see chapter 4) should be started as early as possible.
4. Defects cluster together. A small number of system components usually contain most of the defects discovered or are responsible for most of the operational failures (Enders 1975). This phenomenon is an illustration of the Pareto principle. Predicted defect clusters, and actual defect clusters observed during testing or in operation, are an important input for risk-based testing (see section 5.2).
5. Tests wear out. If the same tests are repeated many times, they become increasingly ineffective in detecting new defects (Beizer 1990). To overcome this effect, existing tests and test data may need to be modified, and new tests may need to be written. However, in some cases, repeating the same tests can have a beneficial outcome, e.g., in automated regression testing (see section 2.2.3).
6. Testing is context dependent. There is no single universally applicable approach to testing. Testing is done differently in different contexts (Kaner 2011).
7. Absence-of-defects fallacy. It is a fallacy (i.e., a misconception) to expect that software verification will ensure the success of a system. Thoroughly testing all the specified requirements and fixing all the defects found could still produce a system that does not fulfill the users’ needs and expectations, that does not help in achieving the customer’s business goals, and that is inferior compared to other competing systems. In addition to verification, validation should also be carried out (Boehm 1981).

 

[The_Doc_Man]

@Edgar_ ... I see you are quoting Barry Boehm among your other sources. I used to have a couple of his books on project management. Sadly, I lost some of those excellent reference works in 2005 in the aftermath of Hurricane Katrina's flooding. However, I remember that Boehm had a LOT of good things to say about testing as well as on pre-planning and about careful selection of project members who were familiar with the project's environment - as opposed to dragging someone "off the street" and expecting rapid productivity. He was big on "learning curves" as well as testing, as I recall.

 

[gemma-the-husky]

Testing has been mentioned multiple times. Here's what ISTQB, an authority in the subject, says about that:

1. Testing shows the presence, not the absence of defects. Testing can show that defects are present in the test object, but cannot prove that there are no defects (Buxton 1970). Testing reduces the probability of defects remaining undiscovered in the test object, but even if no defects are found, testing cannot prove test object correctness.
2. Exhaustive testing is impossible. Testing everything is not feasible except in trivial cases (Manna 1978). Rather than attempting to test exhaustively, test techniques (see chapter 4), test case prioritization (see section 5.1.5), and risk-based testing (see section 5.2), should be used to focus test efforts.
3. Early testing saves time and money. Defects that are removed early in the process will not cause subsequent defects in derived work products. The cost of quality will be reduced since fewer failures will occur later in the SDLC (Boehm 1981). To find defects early, both static testing (see chapter 3) and dynamic testing (see chapter 4) should be started as early as possible.
4. Defects cluster together. A small number of system components usually contain most of the defects discovered or are responsible for most of the operational failures (Enders 1975). This phenomenon is an illustration of the Pareto principle. Predicted defect clusters, and actual defect clusters observed during testing or in operation, are an important input for risk-based testing (see section 5.2).
5. Tests wear out. If the same tests are repeated many times, they become increasingly ineffective in detecting new defects (Beizer 1990). To overcome this effect, existing tests and test data may need to be modified, and new tests may need to be written. However, in some cases, repeating the same tests can have a beneficial outcome, e.g., in automated regression testing (see section 2.2.3).
6. Testing is context dependent. There is no single universally applicable approach to testing. Testing is done differently in different contexts (Kaner 2011).
7. Absence-of-defects fallacy. It is a fallacy (i.e., a misconception) to expect that software verification will ensure the success of a system. Thoroughly testing all the specified requirements and fixing all the defects found could still produce a system that does not fulfill the users’ needs and expectations, that does not help in achieving the customer’s business goals, and that is inferior compared to other competing systems. In addition to verification, validation should also be carried out (Boehm 1981).

No 7. Is what I said. The design commissioners and specifiers may not understand the business needs well enough, and may not understand the development possibilities that are available to produce an optimal (or tending to optimal) solution. The developers may not understand the real requirements.

 

[gemma-the-husky]

Even if it were just an academic interest, the topic would still be of great value to someone who uses Access
Even a linked list or a bubble sort, are purely academic interests (unless one builds a db server or similar), but are still of great interest to understand how things work in certain fields

But this is completely different to choosing an inefficient sorting algorithm.

I don't believe it is of any use to consider the question "what will we do if the problem is too complicated for MS Access". We are doing that continually in a microcosm. Occasional we get queries that are too large to be processed, and we find a way round it empirically.


You seem to be insistent upon arguing about the difference between 2 infinities as it were. I have never had a time when Access has said "this project is now too big". If that happens I will deal with it, probably by dividing the project into two or more parts. Until that happens it's academic, and not really interesting.

 

[Pat Hartman]

Until that happens it's academic, and not really interesting.

And every solution will be different.

 

[The_Doc_Man]

@amorosik - This post is a serious request to review what level of help you have received to date, based on nearly 150 posts on a technical question.

From this forum, you have gotten answers from:

people with an aggregate of at least 200 years of programming experience, probably more than 300 years worth
people with public sector project experience, government project experience, and private business experience
people who hold advanced degrees and with specialty certificates in various topics
people who have started and maintained their own personal businesses
people who have held government security clearances, implying their level of expertise in their field.

But your responses suggest that the above level of resources was inadequate for your needs.

You have continually claimed that you should be able to get specific answers without defining the specifics of the problem. We have disagreed with you and explained why we did so. Members of this forum have tried to help you with advice commensurate with your description of your question. You have continually responded to our answers with a "yes, but..." approach, signifying that you find our advice inadequate, or that you believe we must have forgotten something. While you deny it, MANY of us feel as though your responses are evasive.

Given the kind of diversity and level of experience of our responding members, do you perhaps ever so faintly begin to think that MAYBE the problem is within YOU? Do you think that MAYBE you really don't understand the level of question you are asking? This is not meant to be taken as an argumentum ad authoritatem discussion nor an argumentum ad hominem attack on you.

Please explain why the responses you got so far are not good enough for you. If this forum cannot answer your questions then the only other way we can help you is to direct you to resources you will need to get those answers... if we ourselves know the answers.

 

[The_Doc_Man]

As an aside, do you recall making this post?

What was/is your "largest" access project

After 100 posts there is still someone who insists on recommending the division between user interface and data Perhaps it is not clear to you that the OP has probably already evaluated the matter and has decided, for the reasons he considers important, to maintain the current architecture...

www.access-programmers.co.uk

Did this comment provide a harbinger of your project question?

What was/is your "largest" access project

After 100 posts there is still someone who insists on recommending the division between user interface and data Perhaps it is not clear to you that the OP has probably already evaluated the matter and has decided, for the reasons he considers important, to maintain the current architecture...

www.access-programmers.co.uk

Our answer to you is simple. You cannot tell WHICH limit you will hit, but when you hit one you will know you have screwed up.