comp.software-eng archive file "blurb/stp-teamwork" last changed 31 Jul 1993 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 1 SUMMARY: StP vs TeamWork (Opinions wanted) 1 StP and Teamwork 2 Wanted : Opinions on StP vs TeamWork ------------------------------------------------------------------------ From: djones@cbnewsg.cb.att.com (david.jones) Subject: SUMMARY: StP vs TeamWork (Opinions wanted) Organization: AT&T Date: Thu, 24 Sep 1992 12:25:09 GMT Here is a summary of my recent post "Wanted : Opinions on StP vs TeamWork". I don't provide any comment, and the usual disclaimers about opinions. Many thanks to those that responded. ------------------------------------------------------------- Date: Tue, 15 Sep 92 14:50:41 -0700 From: lana@magenta.corp.sgi.com (Lana Mountford) Subject: Re: Wanted : Opinions on StP vs TeamWork We recently went through a fairly exhaustive evaluation of CASE tools, including IDE's StP and Cadre's Teamwork. Obviously, the choice depends on what methodology you've adopted. We looked at about 20 tools initially, narrowing it down to 8, then down to 3. IDE made the first cut, and lost in the second cut. Teamwork made it to the top 3 and lost out to Associative Design Technology's Ptech. The bottom line for us was IDE's *terrible* E-R modeling approach. Given that we do semantic modeling here, we need a tool capable of supporting a level of 'robustness,' with the ability to be extended if needed. IDE is very limited; requires a lot of manual "tweaking" to force it to accurately represent the relationships, entities, and attributes found in even a simple E-R model; and is VERY inflexible. Teamwork was a step in the right direction, although it is what I would call a "traditional" integrated CASE tool: somewhat inflexible in the way it wants you to enter things, but certainly better than IDE. It wasn't selected here because it hasn't yet been ported to our platform (the Iris). Ptech is actually an OO CASE tool, supporting analysis, design, and code generation (C++), with support for Ontologic's ONTOS OODBMS. However, it is also self-extensible, in that it can be used to create extensions to itself to handle more "traditional" E-R approaches (you simply define a few new classes of objects [ENTITY, ATTRIBUTE, RELATIONSHIP], create their icons, and record the rules/procedures needed to handle them -- piece of cake! :-)) I've also conducted similar evaluations for other companies: Apple Computer (Mac-based CASE tools) and Fireman's Fund Insurance (IBM MVS, IBM PC-DOS, etc.). If you need any further info, feel free to email me. ----------------------------------------------------------------- Date: Wed, 16 Sep 92 06:50:14 CDT From: sessun!clarke@uunet.UU.NET (Allan Clarke) Subject: StP and Teamwork One thing I can say is that our company sells a translator that bridges between StP and our simulation system. AT&T is already a big customer of ours, you might even have someone down the hall using this. For more info call (USA) 512-328-5544. We also have a UK sales office. ----------------------------------------------------------------- Date: Wed, 16 Sep 92 08:20:41 CDT Original-From: sun!richsun.cpg.trs.reuter.com!marke (Mark Ellis) From what I've heard/seen, TeamWork is the way to go. Both are similar in nature, but think TeamWork is more fluid/intuitive and forward looking. The SCCS interface within StP seems buggy (older version under SunView.) ----------------------------------------------------------------- From: M. Obejas Subject: Re: Wanted : Opinions on StP vs TeamWork Date: Thu, 17 Sep 92 14:34:12 PDT To those that may be comparing Teamwork and Software through Pictures: Our company has a sizable population of both Teamwork and StP users. I am strictly a StP user and have not had first hand experience with Teamwork so keep this in mind as you read this. But after reviewing the evaluations written by the Teamwork users I can tell you that I am very happy we made the decision to go to StP. Let me outline the highlights and give you some key points to consider. In the following, Teamwork deficiencies are called to your attention by asking that you check my statements I got this list of Teamwork deficiencies from A CSI report by Karen Westheimer (RSG). Make sure that they are still true in the latest Teamwork version. Be aware that StP has a major release due out at the end of 1992. They have focused on making it faster and easier to use and will be using Sybase or Informix (buyer's choice) for the underlying database. I am a true believer in StP. StP is very open and that is one of its major strengths. If you are using Hatley Pirbhai methods, this is the way to go. 1. Support: My experience with StP is excellent. I call the 800 number and I get people ready to help. I don't get asked what contract I'm on or that they will call me back - I usually get immediate help. IDE also has email via uunet; I have received uuencoded patches via mail at my request before. 2. Open architecture: Some companies claim it - the proof is can you modify and extend it. I have been able to extend StP to do pseudoconcurrent updates. I can also report that it is quite easy to change or add annotations and object attributes. 3. No exclusive user interface: Look into Teamwork's user interface and editor. I think you will find that this is an area where many Teamwork users get heartburn. StP works in your X enviroment and the editor that I use to enter text is MFE (My Favorite Editor). a. Let's say I want to assign a name to an object. In StP, I move the cursor to the object and start typing. I can bump the mouse all I want and the text insertion point remains in place. When I'm done, I click the left mouse key - doesn't matter where. Check if this same scenario causes the text insertion point to drift in Teamwork. b. Let's say you're using explicit keybordFocusPolicy. You click the window and start working. If you click the window again, it's no big deal in StP. Check if you don't get a "Window locked by another user" message in Teamwork. c. If a user has unsaved changes and wishes to quit a graphical editor - or the whole application - StP will request a confirmation to quit without saving. Check if Teamwork provides a confirmation request to quit without saving unsaved changes. d. If I want to set tabs, margins and word wrap, these are normal attributes in StP since I am using MFE. It follows that if I don't want to change my existing settings then I don't have to. Check if the Teamwork text editor is so primitive that it doesn't even allow tabs, margins and word wrap. 4. Flow Diagrams and CSPECs: All of the following are part of Hatley-Pirbhai and are supported by StP unless otherwise noted. Check if they are supported by Teamwork. a. Control stores b. Control flows from a store into a CSPEC. c. Balancing and checking of a two way flow (Note: StP forces you to draw two one way flows). d. Branching and merging of flows. e. Visual distinctions between primitive and nonprimitive processes on the diagram. f. Automatic generation of PSPEC input/output lists when the parent diagram flows changed. g. Support of a "just text" option for a CSPEC. 5. Data Dictionary (DD) work: All of the following are part of Hatley-Pirbhai and are supported by StP unless otherwise noted. Check if they are supported by Teamwork. a. ability to display one DD entry at a time with just the mouse. b. ability to generate flow definitions via a graphical editor as well as via Backus Naur Format entry. c. Ability to regenrate the entire Data Dictionary from scratch via a batch job. 6. Performance: For comparison, note the foloowing and see if Teamwork can match it asssuming the same or more powerful platform. The run was accomplished on a HP 9000/720 PA-RISC machine with these features: - running the HP-UX 8.07 operating system - HP Visual User Environment (VUE- an X and Motif based user interface) active - StP user files on the local disk - 32 MB RAM - 59.5 SPECmarks, 57.9 MIPS, 17.9 MFLOPS (factory ratings) - local and wide area network traffic active. The Metrics run of this model (the THAAD "toc" system) showed the following: - 429 processes. - Maximum flow count among processes = 33 - 2366 data flows. - 88 control flows. There were 5223 objects in the data dictionary of this model. The time to complete varied between 91 and 94 minutes. -------------------------------------------------------------------