Re: What is analysis?

From: paul c <toledobythesea_at_ooyah.ac>
Date: Tue, 04 Dec 2007 00:33:29 GMT
Message-ID: <tf15j.92949$cD.57998_at_pd7urf2no>


David Cressey wrote:
> I had thought that all software engineers were familiar with what analysis
> is, and how it differs from design. But perhaps not. There have been a
> couple of basic questions in this newsgroup, from people that seem like
> serious professionals, that suggest that analysis itself is widely
> misunderstood.
>
>
> Given the number of large projects that have begun with inadequate analysis,
> and have ended in disaster over the last decade, perhaps there's a
> widespread ignorance of the fundamentals of analysis.
>
> 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. 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?
>
> 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.
>
>
>
>

Sorry, I wrote my little tome about analysis under the wrong thread. I was trying to emphasize that to me your question involves asking what are the requirements for analysis. I suspect they are just more specific examples of the requirements for purposeful thought if one were to ask what are the requirements for that. Also I would like to explain that when I mentioned "pat questions", I was including questions one constantly asks oneself, they might be the most important.

No degree, but based on the 70's, 80's and 90's when I haunted university bookstore wherever I went in order to see what the curricula included, I'd say most of the methodology training occurred in a commercial setting, except for the early confusing of structured programming with structured design and the later, phony, higher-education escapades where faculty were fooled into imagining that OO programming must have an analysis and design counterpart.

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

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. Received on Tue Dec 04 2007 - 01:33:29 CET

Original text of this message