An invoicing system is to have the following components: amend invoice, produce invoice,

produce monthly statements, record cash payment, clear paid invoices from database, create

customer records, delete customer. The following physical dependencies govern the order

in which these transactions are implemented.

a$)$

Given the data structure above, the order might be:

Create customer

Delete customer

Produce invoice

Amend invoice

Payment

Clear paid invoices

Produce monthly statements

The last two could be reversed in order. You could argue that 'Delete customer' ought to

wait until the invoice functionality has been developed so that the maintenance of

referential integrity can be assured i$.$e$.$ you cannot delete a customer who still has

outstanding invoices. When an application like this is installed, careful thought has to

go into how the information about existing accounts is to be carried over to the new

application. Obviously details about existing customers will need to be set up before the

new application can become operational. It would be helpful to release the functionality

to set up customer details well in advance of the change$-$over.

Details of invoices that have already been sent out but have not yet been paid would

also need to be recorded for the new application. If the invoices have a lot of complex

detail it might be worth releasing that functionality earlier, even if the users would have

to transfer the invoice number and amount due to their existing accounting system. It

might at least save them typing if the old system is a purely clerical one.

Question: How could the system be broken down into increments which would be of some

value to the users $($hint $-$ think about the problems of taking existing details onto a database

when a system is first implemented$)?$ An invoicing system is to have the following components: amend invoice, produce invoice,

produce monthly statements, record cash payment, clear paid invoices from database, create

customer records, delete customer. The following physical dependencies govern the order

in which these transactions are implemented.

a$)$

Given the data structure above, the order might be:

$$ Create customer

$$ Delete customer

$$ Produce invoice

$$ Amend invoice

$$ Payment

$$ Clear paid invoices

$$ Produce monthly statements

The last two could be reversed in order. You could argue that $$Delete customer$$ ought to

wait until the invoice functionality has been developed so that the maintenance of

referential integrity can be assured i$.$e$.$ you cannot delete a customer who still has

outstanding invoices. When an application like this is installed, careful thought has to

go into how the information about existing accounts is to be carried over to the new

application. Obviously details about existing customers will need to be set up before the

new application can become operational. It would be helpful to release the functionality

to set up customer details well in advance of the change$-$over.

Details of invoices that have already been sent out but have not yet been paid would

also need to be recorded for the new application. If the invoices have a lot of complex

detail it might be worth releasing that functionality earlier, even if the users would have

to transfer the invoice number and amount due to their existing accounting system. It

might at least save them typing if the old system is a purely clerical one.

Question: How could the system be broken down into increments which would be of some

value to the users $($hint $$ think about the problems of taking existing details onto a database

when a system is first implemented$)?$