Re: What is analysis?

David Cressey wrote:

"Jon Heggland" <jon.heggland@xxxxxxxxxxx> wrote in message
news:fj0fhm$ad9$1@xxxxxxxxxxxxxxxxxxxxx

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
craft.


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 "data*** 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 data*** 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.
.