Re: What is analysis?


"Bob Badour" <bbadour@xxxxxxxxxxxxxxxx> wrote in message
news:47540cdb$0$5275$9a566e8b@xxxxxxxxxxxxxxxxxx
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?


No, it is not. There were plenty of technical people in the IT department,
but they were almost all working in the "switching group". This was a group
that tracked the behavior of the cell phone towers, and captured data about
usage, as well as data about malufunctions. The management in that group
was almost entirely engineers.

The management in the group that handled the customer database was business
oriented, and had almost no engineering background. Those that were former
IT technicians had grown up in the files and records era, and both the
relational model and SQL were largely uncharted territory for them. They
relied on the programmers who worked for them to have current technical
knowledge.

The programmers had a rudimentary understanding of SQL, but they didn't
really understand databases.


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.

Probably true. The interesting thing to know is which way the trend is
going. Is management becoming more technically aware or less so? Given how
fast things are changing these days, are managers remaining technically
current as well as honing their management skills? Do they have any
management skills worth honing?

Do they understand the fundamentals of data modeling?



.