goettler@immd2.informatik.uni-erlangen.de (H. Goettler) (02/20/90)
I am gathering material on any kind of diagram technique being used in the software engineering process. I already have lots of information on: Nassi-Shneiderman HIPO SDL JDT ESTELLE LOTOS SD I'd appreciate very much if you could provide me with information on other visualization techniques, which you think are good and should deserve more attention. These visualization techniques need not integrate the whole software life cycle. They might be useful, say, just for requirement analysis, performance analysis, debugging, etc. Herbert Goettler
munck@chance.uucp (Robert Munck) (02/22/90)
In article <2446@medusa.informatik.uni-erlangen.de> goettler@immd2.informatik.uni-erlangen.de (H. Goettler) writes: >...I'd appreciate very much if you could provide me with information >on other visualization techniques, which you think are good and >should deserve more attention. ... >Herbert Goettler SADT is far and away the best visual language for requirements analysis and similar forms of modeling. It is also known as Structured Analysis and Design Technique, IDEF-0, and "State, Activity, Data, Transition". The best published description is "SADT" by Marca and McGowan, McGraw-Hill, 1988. The graphic language is a "constraint diagram," basically a generalization of data flow, flowchart, state-transition, etc. It is, essentially, a more powerful structuring mechanism for natural language, a kind of structured hypertext. Quite powerful CASE tools are available for it. The methodology was developed in the early 70's by Doug Ross and others at SofTech and has been used in many major commercial and military projects; it is a corporate standard for IBM, DEC, Toshiba, Phillips, ITT, and others. SADT is, in my opinion, unique in putting major emphasis on how groups of people work together well. For example, the two-week course spends the better part of a day on "courtesy," an idea rarely mentioned in other methodologies. Other topics include how to get the enthusastic cooperation of overworked experts, dealing with computer-phobes, organizing personal and group files, keeping accurate, complete, and highly-detailed project histories, and resolving controversy. Another example: the peer review procedures put as much emphasis on the understandability of the document as on the correctness of its content. An incorrect document that is understandable can be corrected; a correct document that is not understandable is useless. Questions cheerfully answered. Bob Munck Internet: munck@mitre.org UUCP: ...[backbone]!linus!munck Work: The MITRE Corporation, MS Z-666 7525 Colshire Drive McLean, VA 22102-3481 703/883-6688 703/883-5519 (fax) -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
jkenton@pinocchio.encore.com (Jeff Kenton) (02/22/90)
From article <98229@linus.UUCP>, by munck@chance.uucp (Robert Munck): > > SADT is far and away the best visual language for requirements analysis > and similar forms of modeling. It is also known as Structured Analysis > and Design Technique, IDEF-0, and "State, Activity, Data, Transition". > The best published description is "SADT" by Marca and McGowan, > McGraw-Hill, 1988. > > The graphic language is a "constraint diagram," basically a > generalization of data flow, flowchart, state-transition, etc. It is, > essentially, a more powerful structuring mechanism for natural language, > a kind of structured hypertext. . . . > > SADT is, in my opinion, unique in putting major emphasis on how groups > of people work together well. Does anyone else have any experience with this? About 8 years ago I was part of a startup which had a person who had been at Softech. He tried to promote SADT, but wound up creating friction and blocking progress in many imaginative ways. He left after 9 months without having written a single line of code, and a demo scheduled for the board of directors in two weeks. Was it him, or us, or SADT? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
sdl@lyra.mitre.org (Steven D. Litvinchouk) (02/24/90)
In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: > About 8 years ago I was > part of a startup which had a person who had been at Softech. He tried > to promote SADT, but wound up creating friction and blocking progress in > many imaginative ways. He left after 9 months without having written a > single line of code, and a demo scheduled for the board of directors in > two weeks. > > Was it him, or us, or SADT? There's an obvious question. How well did things go on the project *after* this person left? Did the non-use of SADT afterwards produce demonstrable progress? Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mbunix.mitre.org UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" -- J. Nicholson -- Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mbunix.mitre.org UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" -- J. Nicholson
cs86eew@cc.brunel.ac.uk (Eoin Woods) (02/28/90)
In article <SDL.90Feb23164916@lyra.lyra.mitre.org> sdl@lyra.mitre.org (Steven D. Litvinchouk) writes: > >In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: > >> About 8 years ago I was >> part of a startup which had a person who had been at Softech. He tried >> to promote SADT, but wound up creating friction and blocking progress in >> many imaginative ways. He left after 9 months without having written a >> single line of code, and a demo scheduled for the board of directors in >> two weeks. >> >> Was it him, or us, or SADT? > >There's an obvious question. How well did things go on the project >*after* this person left? Did the non-use of SADT afterwards produce >demonstrable progress? > Even if there was progress, it does not really refect positively or negatively on the SADT method. Promoting a tool is one thing, blocking a project and making it run late is surely unprofessional in the extreme. It sounds as if the Ex-Softech-ie was getting mixed up between the use of SADT specifically and using good software development method. Presumably you were using a method but they thought it could be done better with SADT. I could have been you, it probably was him but it can;t have been SADT - It can't produce friction - only the human's using it can!! Besides, I think SADT is really quite good ! Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | FROM : Eoin Woods Computer Science Department, Brunel University, | | Uxbridge, Middlesex UB8 3PH | | JANET : cs86eew@mercury.cct.brunel.ac.uk | | UUCP : ...ukc!cct.brunel!cs86eew | | ARPA : cs86eew%cct.brunel.ac.uk@cs.ucl |
wdr@wang.com (William Ricker) (03/02/90)
cs86eew@cc.brunel.ac.uk (Eoin Woods) writes: >>In article <11202@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: >> >>> About 8 years ago I was >>> part of a startup which had a person who had been at Softech. He tried >>> to promote SADT, but wound up creating friction and blocking progress in >>> many imaginative ways. He left after 9 months without having written a >>> single line of code, and a demo scheduled for the board of directors in >>> two weeks. >>> >>> Was it him, or us, or SADT? >I could have been you, it probably was him but it can;t have been SADT - It >can't produce friction - only the human's using it can!! As an ex-SofTechie who was annoyed that SofTech never trained him in SADT, but has worked elsewhere with ex-SofTechies even more arrogant than myself, including one SADT co-developer, I suspect the friction was produced (a) by the ex-SofTechie, a lot of us have awfully good opinions of our own opinions, consulting houses breed that; and (b) aggressively ramming his favorite methodology down peoples throat as *the one true way*. If the original poster would like to mail me the name of the suspect *privately*, I might be able to reply more conclusively as to his reputation and likely guilt or innocence. If I don't know him, one of my even-more arrogant ex-colleagues can tell me... Note that a good designer *can* be an asset to a project even if s/he never writes a line of code. But a good analyst/designer by definition is a builder of consensus, not friction. The JAD methodology from PRI is the "hot" new replacement for SADT in this area. >Besides, I think SADT is really quite good ! I rather like it myself. I do note that both L.J.Peters and C.F.Martin comment that it, like abstract DFD octupi-charts, are difficult to explain to the sponsor-clients of large systems (executives, not programming managers); and that SADT reviews with less experienced or less trusting reviewers drop into gnit-picking about "why is this flow/arc a control not data?" when what should be discussed is three-boxes or four-boxes to decompose this node. We have stolen the "kit" and "author-reader cycle" concepts from SADT, whereby people provide 12-48hour turnaround on small pieces of spec, with context and feedback, in a structured interaction, without benefit of conference room. And we use whatever diagram style fits, or just memos (usually from an outliner) for the body of the "kit". Bill Ricker