Re: What is analysis?

"Jon Heggland" <jon.heggland_at_ntnu.no> wrote in message news:fj14mv$n05$1_at_orkan.itea.ntnu.no...
> Quoth David Cressey:
> > "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> > news:fj0fhm$ad9$1_at_orkan.itea.ntnu.no...
> >> [...]
> > 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".
>
> Yes, I was thinking about analysis and synthesis when I spoke my piece.
>
> >> 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.
>
> I was half hoping that you might know of any science in the area, since
> you used the term "formal analysis" earlier, and seemed surprised that
> there is confusion about what analysis is. Oh well. :)
>

I don't think of "formal" as a code word for "scientific". In fact, I don't even think "engineering" is code for "scientific". Science is about discovery. Engineering is about invention. There is a lot of overlap in the language, the tools, the method and the mode of thought. But they aren't interchageable.

> >> 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.
>
> "Approximation" sounds strange to my ears in this context; I usually
> talk about "iterative development". Which goes almost without saying; I
> can hardly imagine building an information system any other way. The
> users have hardly any idea what they want until I show them something.
>

I'll accept "iterative development" as better sounding than "successive approximation".

And I'll accept that information systems evolve along with changing requirements. But
I'll also claim that some good analysis can accomplish in weeks when take months worth of iterative development. I've seen analysts that are better than I am doing their work. It's really impressive, except that the interviewees are generally nuimpressed. One manager's summary: "He's not very bright, but at least he's thorough." What the manager didn't know is that the analyst deliberately asked the same question over and over again in different words. If he had gotten different answers each time, that would have told him something he needed to know.

> > 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"?
>
> I'm not familiar with Access. My tool of choice, Dataphor, creates GUIs
> from table (or rather view) definitions. There isn't any clear
> separation between the database and the application(s). So I show them
> the actual application, which shows actual database tables/views quite
> plainly.

Fair enough. That's really what I was after. I hold no brief for Access. It's just that it existed on almost every desktop that I used at a client's site, it was easy to link to "the real database", and it had a very easy learning curve, from my point of view.

 > Sometimes I draw sample tables (with example data, not just
> headings) on a whiteboard or something. And sometimes I use an ER-like
> notation (Carlis and Maguire's LDS), but with a strict and simple
> correspondence to my relvars. The relvars come first; the diagrams are
> simplifying representations of them.

It would be interesting to know if there is a way of deriving relvars from some form of data analysis that doesn't involve ER. I am convinced that a set of relvars embeds design decisions, but I don't know from direct experience. What do you say?

>
> > 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.
>
> I don't consider foreign keys all that special. It always annoys me when
> someone says that foreign keys signify relationships. They don't; they
> /constrain/ relationships. Relationships are given by attributes being
> defined over the same domain (although this makes far more sense if your
> DBMS has proper domain support). Anyway, I don't feel the need to talk
> much about foreign keys. I talk about identifiers (key constraints), and
> say that this column/attribute is the same as that.
>

The word "signify" strikes me as odd and stilted in this context. I prefer to say that "foreign keys represent relationships."

> > 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.
>
> That fits with my experience, too. But "back into ER form"? Did it start
> out that way?

No, I didn't mean "back" that way. What I really meant was "backwards".

>
> > [...] I will admit that MOST of
> > the communication was in the form of questions and answers in plain
English,
> > rather than the diagram itself.
>
> Ditto. Except, y'know, Norwegian. :)
>
> > Where the diagram added value is that it kept the conversation moving
> > forward, instead of going around in circles.
>
> Yes. One must have some sort of artifact to point at and scribble on.
>
> > 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.
>
> No? I'd say it was, but an analysis of the database, not the business
> problem.

Well, yes. After a while, the database becomes "a part of the system". At that point, system analysis includes database analysis. Since I came to this case late in the game, the database was already "part of the environment" a far as most of its stakeholders were concerned. Received on Mon Dec 03 2007 - 17:11:15 CET