Continued from page 1
Top business experience is required in
analysis team in order to get in-depth understanding of business itself.
Remember: Our model, at this stage in development, must reflect business, not some constraints given by any tool or personal preferences. This happens all too often and usually with not-to-good results.
In analysis team, system analysts must have an expert level knowledge of business modeling. By business modeling, I mean exactly that. I do not mean expert knowledge of f.i. Entity Relationship modeling without relating it to real world. However good a person may be educated, nothing beats experience earned from several similar tasks at equivalent level of complexity. How does one gain experience then? Participate under a tutor. I would never hire a consultant without experience and trust her to understand complexity of my business, all by herself.
I will not go into detail as to total project staff is composed. This will depend on many outside factors, such as degree of participation from each party, size of project, formal requirements (public sector tends to require at higher level of project staffing, partly due to rigorous documentation requirements), etc. What we focus on is tightly performing party that determines final business model: The experts on business together with system analysts, preferably more than one in this phase.
Due to increasing complexity that tends to be taken into systems development, I cannot imagine a development project of any noticeable size that should not use a development tool as support for analysis team as well as for each stage other of development. I regard tool(s) chosen as an integral part of team. In many cases, tool is also communicator between business and analyst. I have often started a project by going through way we communicate with each other. In my experience, business soon finds Entity Relationship diagrams familiar, if not as familiar as to system analysts. However, they are a means of communication that work. The same may be said for function diagrams, or function hierarchies. They are even easier to understand for a non-system person.
That is why eBook on ‘Entity Relationship Modeling – Principles’ is in writing, and soon will be published on this site as a free eBook, which you are free to use in your ongoing or upcoming projects.
As for choice of modeling tool, I give no concrete recommendations: I have used Oracle Designer (formerly Oracle CASE*Method) for last 15 years, and I have found it to be a powerful and rich system, which delivers in many more areas than I have needed to use it for. I am probably a little biased here.
However, a toolset should include reusable objects: The results from analysis phase should be basis for generating tables and all other database objects for use in design phase, as well as functions should be used for generating candidate modules. Furthermore, database objects and candidate modules should be used to generate DDL (Data Definition Language) scripts for physically building all elements of database, as well as candidate modules should be used to generate running program modules. Not that I expect a system to be 100% generated – far from it. However, with such functionality you could show a prototype, which illustrated resulting, needed functionality, but without last finishing touch or most advanced business constraints built into it.
For more visualization of this article, visit http://www.databasedesign-resource.com
The author has spent the last 15 years as a system analyst in manufacturing, government, private corporations and broadcasting, performing database analysis and design, based on Oracle Designer and Developer tools.
