Database Management

[vanskat]

I'm primarily a power engineer but have been awarded the task of creating a web-based database management system. I've got a high aptitude for this stuff (hobby). Essentially I'm responsible for the conceptual design which is complete. I've outsourced the technical aspect to some consultants who have replied saying that they need more details on the project scope in order to put a cost to it.
My question is: what sort of information is required by a programmer in undertaking such a project? Deliverables, specific requirements, construct, data? Isn't it enough to communicate what u want but the how is something the consultant deals with?...........

 

[Ransom]

Whilst we actually undertake this sort of work - see inspsoft.com. We suggest the following;

1. All software consultants will be viewing the project from a completly different point of view and concept, so ensure you have VERY firm reins on the project and budget. 75 percent of software budget on start go over by 50% !!!

2. See if you can located the 'BS Standard Tickit' document. This lay out exactly where client and software developers stand and what is expected at each stage of works. It is our bible on new work. Whilst it might be 10 years old now..it is still the most valid document in this case Daniel Mulcahy
Information given is free with no strings attached.

 

[RivieraCadMan]

Myself and a fellow employee have been building just such as system in time as we write the company work order/GIS/inventory system. The important thing to remember is to plan your project completely and fully before undertaking, and to keep the system as modular as possible. There is no true sure path of producing this form of system. Select a good foundation of products that can handle all the various forms of data you want to exchange. I don't suggest you build a great deal of scripts into your server for it eats bandwidth up quickly. Find your access points and derive groups for various users. Try to keep page design close to paper systems that are being used. (save you a great deal of time in the long run) Share data between departments.(such as customer data) Allow very limited customer access or use a separate branch of tables to be accessed by customers.(This will keep bandwidth in your database open for employees)
Our system can send/receive information directly from our AS400 and Access (access front end Pervasive server) databases, our digital cable system controllers, our gas, water, and waste water integrated SCADA system, our electric SCADA system, our mapping system, and warehouse scanning systems. Currently we have about 35,000 electric customers 8,500 water customers, 8,000 gas customers, and 12,000 digital cable customers. Our system runs throughout the company via web browser and custom access front end with pervasive back-end and on a Novell fiber network. AutoCAD Map allows editing of the map database which is automatically changed to *.dwf format every evening. All data in Access(Pervasive or also known as Btrieve) is live and posted on the AS400 for storage in the evening. Gas and water system analysis is done in lotus, but will soon be in Map. In the very near future a WAN will provide data exchange with field units via laptops.
Our biggest problem to this point is that there are very few data entry personnel who can enter, data and of those only my friend and I have the companies permission to view all the data for security reasons. A great deal of our time is consumed simply explaining how to use the software. Another smaller problem has been the use of proper hardware through out the company. I was hired as a draftsman and my friend a warehouseman yet we control all internet applications, mapping, database, inventory, and most of the SCADA hardware and programming for the company. Our current system has taken two years to build. I hope this helps and gives you an idea of what your in for in the future.

 

[TonyMcG]

Start with the data and find a decent ERM - otherwsie you'll be chasing processes (functionality) and incurring larger and larger expense to make it work in the future. A good database design at the outset at least lets you build the functionality on a solid supportable base.