Re: What is analysis?
Date: Mon, 03 Dec 2007 10:04:05 -0400
Message-ID: <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?
> 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. Received on Mon Dec 03 2007 - 15:04:05 CET