Path: text.usenetserver.com!out02b.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!nx01.iad01.newshosting.com!newshosting.com!post01.iad01!news.aliant.net!not-for-mail Date: Mon, 03 Dec 2007 10:04:05 -0400 From: Bob Badour User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.databases.theory Subject: Re: What is analysis? References: <%hT4j.2188$3W.1946@trndny04> In-Reply-To: <%hT4j.2188$3W.1946@trndny04> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 127 Message-ID: <47540cdb$0$5275$9a566e8b@news.aliant.net> NNTP-Posting-Host: 142.176.57.49 X-Complaints-To: abuse@aliant.net Xref: usenetserver.com comp.databases.theory:167796 X-Received-Date: Mon, 03 Dec 2007 09:04:12 EST (text.usenetserver.com) David Cressey wrote: > "Jon Heggland" wrote in message > news:fj0fhm$ad9$1@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.