Re: What is analysis?

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

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". Received on Mon Dec 03 2007 - 14:13:31 CET