Re: One-To-One Relationships

David Cressey wrote:
> "Cimode" <cimode_at_hotmail.com> wrote in message news:b9592be8-2ddb-4ead-
>

>> It seems we both have a communication problem...I am truly trying hard
>> to give a chance to E/R modeling...

This thread could be compared to a "request for requirements definition", or the seemingly simple question "how does one think systematically?".

Regarding psychology, in practice you have to start somewhere and one might prefer to start with predicates or entities or processes or even nothing but business metrics concerning the final result. Whether you can get away with your beginning preference for how to identify requirements depends on who you are talking to. Sometimes people refuse to talk about anything except "processes" and you need to be a detective to discern that two different people are really talking about the same data. You have to take what you get. David C is right that psychology is involved, this is no disgrace and also that various "interviewing" styles are known to help with this. Assessing it all is also a skill that improves with practice and from the psychological field has come various advice for helping that, eg., Edward de Bono's books about thinking aren't aimed at IT people even though they often apply. Among other things he recommends having pat standard questions that are always asked, even though many of them may appear wasteful in any given situation.

For old-timers like me it is very hard to dissociate analysis as a mental skill from a job position or step in a methodology. Large organizations very much prefer to turn the noun that means analysis into a noun that means analysis department or a noun that has a planned time and a deadline. Even orgs that promote iterative development like to have formal steps or formal positions. There is a difference between a formally established activity and an activity that involves applying selective formalities to aspects of a system. Somebody who is skilled only in normalization might easily forget that ultimately a system is involved.

I noticed David C was careful to limit the size of a system in his original question. This helps limit his question to how does the individual proceed to think in an analytical way, regardless of the culture or organization around him. Even though reason or pure rationality are evidently the central essence of a useful system, they are not always enough for making one. Part of the 20th-century "systems thinking" involved the hope that some formal, eg., mathematical, analogy could be discovered for any large-scale human activity which would then provide a roadmap for the "ideal" analysis result. The word "analysis" was at the centre of this movement. History and human nature have helped discredit the ambition to have a be-all and end-all methodology.

Some people are born to analyze well and are dissecting, synthesizing, re-formulating all the time even when coding. Others learn how to do it acceptably but forget the analysis dimension depending on what activity they happen to be focussing on. Some are incapable or unwilling to practise either.

There is much in the psychological field that helps focus analysis ability and it's still being added to. There is some value in making sure blood sugar levels are right and some psychologists recommend using a highlighter in unconventional ways when reading material, eg., dividing the page into quadrants as opposed to just underling phrases.

I have even noticed a psychology of requirements where the initial requirements are stated at such length and so clumsily that there is no hope for a single individual to imagine a coherent implementation of even a small part let alone any hope for a collective implementation. The thing I noticed about requirements is that you start with them and you finish with them and there is often a correlation between the starting set, the finishing set and a system's deemed success. Design documents are a similar story, I remember several, like this, eg., one was 156 pages long and was argued over for a year, nobody knew which page the design was on. It was written by highly-skilled communication   technicians. It took some courage to throw that effort in the garbage and start over. It wasn't discarded though until somebody took the trouble to write a one-page rationale. Although that rationale was eminently coherent, it was immediately obvious to all involved that its result was not what was wanted. The next effort made sure to re-visit a new one-pager at every meeting and was implemented in less time than the original effort. Some involved thought the reason was better insight, some thought better structure was involved, I thought both.

I was disappointed to see Gerald Weinberg's wiki entry red-lettered his Psychology of Computer Programming book. He wrote others on analyis. I thought they prepared me better than the methodology-oriented systems analysis books by numerous people, starting back in the 1970's with ones by a guy named Pressman, ending a few years ago with the "extreme programming" series, and a lot of bumpf in between. There was some good advice on specific analysis techniques in all of them, but I suspect Edward de Bono could have edited the same material down to 5% of the volume. No matter how much innate analysis talent one has, it improves with practice.

That's enough of that for me, at least for today! Received on Mon Dec 03 2007 - 19:12:26 CET