average monthly report

[Mike or Penny Novack]

>>
>>Can you explain me please what does "submitting" means here?
>>If you need a person who will say "yes, I need it", I can be this 
>>person for sure.
>>But there will be no use from me if volunteering=programming - I have almost
>>no experience here.
>>    
>>
>
>  
>
However do not underestimate the need for "end users" in various phases. 
SIMPLY making a request isn't very likely to result in what the end 
users want even when the programming resources are available. End user 
input/cooperation is required for:

1) The REQUIREMENTS phase. Not just a roughly specified request but 
EXACTLY what is this feature supposed to do. Otherwise there is little 
chance that the end user's expectations and the programmer's 
understanding of those will match.
    EXAMPLE (in this case)  ---- what do you mean here by "averaging" 
and precisely what does that mean for budgeting purposes. Speaking as an 
experienced analyst who has spent decades trying to figure out what the 
client REALLY wants/needs I have some suspicions here. IMHO a budgeting 
process has to take into account not only will the averages be OK but 
that the CASH FLOW will remain positive throughout the period. If not, 
then this "average feature" would be useful only for the budgeting needs 
of organizations that can presume unspecified lines of credit. But note 
that even in this case having a cash flow issue affects the budgeted 
amounts (you have to pay interest on amounts borrowed to deal with cash 
flow issues, yes?).

2) DESIGN phase. The analyst will surely have all sorts of "details" 
questions that weren't settled in the requirements phase, little (or not 
so little) things that come up when doing the actual design.

Now the client can take a break until.

3) TESTING phase. The programmers test till there are no hangs and they 
THINK the new feature is doing what it is supposed to be doing. But it's 
the end users and their requirements that matter. However this "user 
testing" has to be cooperative with the programmers suggesting "odd 
cases" that the the clients wouldn't have likely thought of on their 
own. Natural for users to think only about the usual/common cases but in 
a real project, about 80% of the code is handling all the various 
oddball situations which can be expected "only when the moon is in some 
odd phase" (NOTE: for those of who enjoy the challenge, these are the 
fun bugs that appear "but the program has worked just fine in production 
for ten years, why is it hanging now?")

SO --- I would say that any users making requests should be prepared to 
do THEIR part of this should programming resources agree to take on 
their request. As a potential resource, I will say loud and clear that 
any willingness on my part to "code something" would be conditional on 
the requester persons being willing to commit to their part.

Michael