Re: What is analysis?

From: Bob Badour <>
Date: Mon, 03 Dec 2007 10:04:05 -0400
Message-ID: <47540cdb$0$5275$>

David Cressey wrote:

> "Jon Heggland" <> wrote in message
> news:fj0fhm$ad9$

>>Quoth David Cressey:
>>>I'm hesitant to offer a definition off the top of my head,  because it

> will
>>>surely be torn apart by the usual gang of vultures.
>>I'll have a go, then: Analysis is taking something apart (to see how it
>>works). Whereas design is putting something together (to make it work). :)

> I like this a lot better than my own attempts. I this case, I think it
> means "taking the problem apart". Breaking the problem down into pieces
> that are easily assimilated. The term "easily assimilated" has more to do
> with psychology than logic, so we should be prepared for the general
> complaint that "analysis is subjective".
> In the above terms, the opposite of analysis is synthesis. I like to think
> of the overall life cycle as consisting of "problem analysis and system
> synthesis".
>>>In the meantime,  I'd
>>>like to hear from everybody with a degree in software engineering.  Did

> you
>>>ever take a course on analysis?  Or, alternatively, did you ever take a
>>>course on methodologies that put a strong emphasis on analysis?
>>No. Nothing that covered analysis /thoroughly/, at least, and certainly
>>not /formally/. I've learned a few diagramming notations in my time, but
>>I've never had analysis presented as a science as opposed to an art or

> Maybe it is an art or craft rather than a science. Maybe presenting as if
> it were a science is missing the point.
>>>Have any of you ever undertaken a large scale database design project
>>>without doing any formal analysis,  or just by writing down the

> requirements
>>>in a doc?  What happened after that?  I'm not talking about a little
>>>database with 20 or 30 columns.  I'm talking a database with upwards of

> 300
>>>columns and a good number of tables.
>>I have a database of currently 102 relvars with in total 590 attributes.
>>No formal analysis, whatever that means. I drew some pictures in the
>>beginning for communication, but once I had a prototype, it was simpler
>>to just show, tell and ask. People understand tables just fine. What do
>>you mean, "What happened after that?"

> I think you answered the question. You raise a very important point:
> prototyping
> and successive apporximation. You didn't say successive approximation, but
> I'm inferring that from the word "ask". Prototyping has always been an
> attractive alternative to analysis.
> I would certainly prefer prototyping to what has been called "analysis
> paralysis". In fact, I'll go so far as to say that prototyping, done
> properly, is itself a form of analysis. It blends analysis with design in a
> ways that classical analysis does not. However, I've seen prototyping done
> wrong, and that can lead to disaster.
> How do you show people a table? Do you se a diagram? Do you show the table
> through the lens of the application you are building? Do you give them what
> MS Access calls a "datasheet view"?
> Do your people understand foreign keys just fine? My experience, going
> back to the 1990s was that people who had not worked with databases did NOT
> understand foreign keys just fine. That includes people with 20 years COBOL
> programming experience and who were in other respects highly proficient.
> Managers also couldn't get "the big picture" from a datasheet view.
> My biggest success with diagrams did not come from the analysis of a
> proposed system. It came from reverse engineering an existing database back
> into ER form, and using that diagram to communicate with managers and
> programmers.
> I used a tool to perform the busy work. It took me all of one day to
> extract the metadata from the devlopment database, generate the ER diagram,
> make subsets of it for presentation purposes, and copy the result to
> transparencies (yeah, I know, that's primitive). I will admit that MOST of
> the communication was in the form of questions and answers in plain English,
> rather than the diagram itself.
> Where the diagram added value is that it kept the conversation moving
> forward, instead of going around in circles.
> The database was about 100 tables, and maybe 600 columns. I forget how many
> entities and relationships I ended up with, but it was about 100 in total.
> That's because every table describes an entity or a relationship. There are
> a few extra relationships hidden in entity tables, and there are few tables
> that are "about nothing" in the Seinfeld sense.
> Before I did this, the only person who understood the database was the DBA.
> After I did this, almost all the stakeholders understood it. This was not
> analysis. The database was about customer relationhip management in the
> cell phone industry.

Since it was the telephone/telecommunications industry, is it fair to say most of the managers had an engineering background?

> When I built new databases, much smaller and simpler, I used diagrams for
> my own purposes. It was much easier that keeping the details in my head,
> or writing the details in formal English in a doc, or embedding the details
> in code. I also found that diagrams were much better and faster at
> communicating with management than "progress reports".

I suspect you have worked with a different sort of management than I have. Received on Mon Dec 03 2007 - 15:04:05 CET

Original text of this message