Re: What is analysis?

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:47540cdb$0$5275$9a566e8b_at_news.aliant.net...
> David Cressey wrote:
>
> > "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> > news:fj0fhm$ad9$1_at_orkan.itea.ntnu.no...
> >
> >>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 "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?
>

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? Received on Mon Dec 03 2007 - 15:37:54 CET