Auctioneer-antique database application
A local auctioneer-antique shop (Antik Boutik Limited) sells and stores antiques for their owners in their strong room. The majority of their income comes from commission paid on sales, storage charges and insurance charges.
Commission for a sale is 15% of the selling price and the new owner is to pay. The insurance charge is 10% of the asset value payable at the beginning of the year and there is no refund. The storage cost is 5% the value of the asset, and a client has two weeks to settle the bill.
As a result of inconsistency in the current manual system, and in consultation with the operations manager you are asked to analyze and develop a computerize database application to replace the manual system. The new system must be able to perform the following functions:
Keep track of income by raising the necessary invoice (bills) for sales of assets so the company can claim their commission
Produce records of assets owned and stored by the company
Produce annually or as required insurance demands and storage charges for the owners of the antiques they keep for them in their strong room
Issue the necessary change of ownership forms when an item has been sold
The project aims to produce a database design and implementation using an appropriate relational database management system, and a front-end application program that will allow users of the antiques shop access and manipulate the data in the database.
For the database design I intend to use Entity Relation Diagramming (ERD) and the physical database I also plan using Microsoft Access 2003. However, with the front-end application Java Swing Package API will be used to build the interface along side Java Database Connectivity.
Presently I have to schedule several visits to the company and interview the staff about what kind of data they collect, the operations manager has also agreed to answer any question relating to the manual system that will enable me model the database using Entity Relation Diagram that will serve as a blueprint to build the MS-Access database tables and fields and relationships amongst the tables. Also I will be studying the company's input forms they use to collect information, and the invoice layout and content to enable me build realistic information system that will replace successfully the manual system with minimal difficulty.
As to the programming and developing the front-end, I have studied and researched on the Java Programming language, particularly the swing package and Java database connectivity that allows client application to connect to external database and issue SQL queries.
Java actually does not have any inbuilt database sub-language so a standard language, like ANSI-SQL, must be used to build the query of which I have several books, both electronic books and physical ones as reference, in case of further research is needed.
Project Main sub-tasks
During analysis, actually I will have to visit Antik Boutik Limited to interview the staff and other managers, and also to study the system of operations in order to appreciate and gain an understanding about the antiques business. As the saying goes, one cannot build information systems suitable for a company unless one understands the problem at hand. The information gathered at this point will help me model the operations of the antique business using dataflow diagram (DFD), and entity relation diagram (ERD). The end result of the analysis will be a documentation which will contain the data flow diagram, and other narratives called requirement specification.
Whereas analysis is concerned with specifying, or making clear, a requirement, design is concerned with developing a solution at the abstract level. Design is actually in two parts designing the data model that will support the system, and the front-end application that will manipulate the data. The data model will be used as a blue-print for the database, and the DFD processes will be converted to flowchart or pseudo-codes.
By implementation I mean using the design as a template for building or developing the application itself and its companion data. Java and SQL (Structured Query Language) scripts will be used for the front-end application and MS-Access 2003 for the database schema.
Testing & Evaluation
Testing is a way of validating and verifying that the software or system developed will meet the specified requirement as was documented at the analysis stage. There is the developer testing using test data, both good and bad, and documenting the result. Then there is the user testing where the system is tested in the user's environment and subjected to usability testing.
Project Life Cycle
I am very confident that though the above project seem to be in two parts though, to me, from a programming standpoint, it is actually one part project because the database part can be developed in MS-Access 2003 without any coding at all, and as such I have a adopted the Waterfall approach.
The waterfall model was originally published in 1970 by Royce. In this model, system development is broken down into a number of sequential sections or stages represented by boxes, with each stage being completed before work starts on the following one. The outputs from one stage are used as inputs to the next (Yeates and Wakefield, 2004).
This is illustrated by the 'flow' from one stage to the next. For example, using diagram in Appendix A, the product design products are completed and accepted before being used as inputs to the work of the next stage, detailed design, and so on. Each stage is divided into two parts: the first part covers the actual work being carried out in the stage, and the second part covers the 'verification and validation' of that work.
Verification is taken to mean establishing the correspondence between a product and its specification - in other words, are we building the product in the right way? Validation, on the other hand, is concerned with whether the product is fit for its operational mission - in other words, are we building the right product? (Yeates and Wakefield, 2004)
Typically, there is a degree of iteration of work and products within a stage, but very little between stages. Rework, where necessary, is carried out in succeeding stages, and the original stage in which the product was produced is not revisited. For example, if a new requirement is identified during the detailed design stage, the project will not return to the software plans and specification stage but will incorporate the reworking within the current stage.
Waterfall models work best when the level of reworking of products is kept to a minimum and the products remain unchanged after completion of their stage. In situations where the requirements are well understood and the business area in general is not likely to undergo significant business change, the waterfall model works well.
In situations where the business requirements are not well understood and where the system is likely to undergo radical change, a different approach from that suggested by the waterfall model may be more appropriate.
The waterfall model is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible, for any non-trivial project, to get one phase of a software product's lifecycle perfected before moving on to the next phases and learning from them
For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested in Big Design Up Front. Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product.
That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas (McConnell, 2004).
Project Plan and Schedule
The following table is the Project's Activity Dependency Chart, and total duration for the project is 280 hours
Systems Analysis and Design, Donald Yeates and Tony Wakefield, 2nd Edition, Prentice Hall, ISBN: 0273 65536 1
Java How to program, H. M. Deitel and P. J. Deitel, 6th Edition. Prentice Hall, ISBN: 10:0-13-148398-6, 2004