Re: What is analysis?

"paul c" <toledobythesea_at_ooyah.ac> wrote in message news:tf15j.92949$cD.57998_at_pd7urf2no... [snip lots of good material]

> ... where faculty were fooled into imagining that
> OO programming must have an analysis and design counterpart.

I, on the other hand, am fooled into believing that OOA and OOD are quite interesting, but OOP is a waste of time.

>
> Much of that training was product-biased. Still, I met a small handful
> of analysts who were comfortable no matter the tools, might even write
> prototypes from time to time, in two or three different languages. By
> comfortable I mean they remained steadfastly concise in their
> explanations regardless of the concepts a tool or culture required them
> to manipulate. Whereas most practitioners I knew tended to regard a
> methodology as a recipe, not unlike one to cook Bouillabaisse. Also job
> security as unlike a chef, they didn't have to succeed every night. Not
> to disparage ER, but it is not a requirement for analysis. (Nor are
> predicates although it is notable that unlike ER, they are involved in
> the result.)
>

The problem with comparing a methodology with cooking Boullabaise is that once you have successfully coooked a Boullabaise, your goal is to get the same result over and over again.

One typically applies a given methodology to problems one has never seen before (although some patterns recur). So methodology is more like "cooking a brand new dish, and having it come out right the first time.", and doing that repeatably.

> What was really remarkable to me was that I worked with people who had
> as many as three math degrees who had never taken a logic course but
> knew only what SOL meant, not FOL!
>
> Once a database approached 1,000 columns, I found it was rare that any
> one person was responsible for any one aspect of its development, such
> as analysis of the whole system (apart from administrative functions
> such as change control), let alone who could explain all of its
> functions to a programmer as well as management. At that point, fences
> needed to be put up to maintain any kind of personal control, ie., to
> maintain the authority/peer respect needed for one to be seen as
> responsible for whatever aspect. I used to dream how nice and simple
> life would be if I could work on a system with only 300 columns. I
> hated mornings because the dreams ended then.

Fences can be useful, but there are aspects of data management that cut across the fences.
And they aren't just administrative functions. Received on Wed Dec 05 2007 - 20:25:03 CET