hsrender@happy.colorado.edu (06/06/91)
In article <1991Jun6.125833.18549@dec254.uucp>, toolsmit@dec254.uucp (Toolsmith) writes: > My point is that I think we (the software engineering community) need to > establish some sort of program or process to define accepted practices in the > same sense as the accepted practices of the other engineering disciplines. > > Anyone care to comment? A few comments: First, the IEEE is trying to do this (after a fashion) by establishing guidelines and standards for various kinds of project documents (Requirements docs, design docs, user docs, etc.) They also have standards for creating QA plans, CM plans and test plans. Together, these go a fair way towards defining what it is that a software engineer is supposed to know about and do on the job. The DoD's 2167 standard also seems to have this goal in mind. Second, a problem with the standards is that they tend to "freeze" the current way that things are done (at least if they are followed to the letter). This can stifle innovation. Since I think very few people would say that we now know exactly how software should be created and maintained, anything that leads people (particularly project sponsors and managers) to think that we do could inhibit their acceptance of new ideas. Third, there is some certification for programmers. I know that there is a Data Processing Certificate (or something like it) that one can receive by taking some kind of test. I know this because I have seen study guides for the test in amongst the Schaum's outlines in the local bookstore. It seems pretty much a test of terminology and a few practices. I think such a test could be useful for certifying software engineers if we ever do come up with a standard set of terminology and practices. hal.
toolsmit@dec254.uucp (Toolsmith) (06/06/91)
I have this (probably naive) thought that what we really lack in the field of software engineering is a complete set of "accepted practices". Other engineering disciplines such as mechanical, electrical or civil have a well developed and widely understood set of accepted practices, some of which are embedded in formal codes (i.e. the electrical code). People engaged in the other engineering professions also enjoy(?) the legal status of professional certification. Anyone heard of a registered professional software engineer? The exams for certification seem to me to be a means for assessing the engineer's knowledge of accepted practices in his/her discipline. I think the reason for this situation is that the software engineering profession is quite immature compared to the other engineering professions. The underlying theory of current practices is not as old (well-tested) as that of the other engineering disciplines and is not as complete. My point is that I think we (the software engineering community) need to establish some sort of program or process to define accepted practices in the same sense as the accepted practices of the other engineering disciplines. Anyone care to comment? --------------------------------------------------------------------------- | Bill Brown |voicenet: (513) 841-8646 | | Cincinnati Milacron Inc., Dept. 82G |uucp: uunet!dec254!brown | | 4701 Marburg Avenue |also: uunet!dec254!toolsmit | | Cincinnati, OH 45209 |compuserve: 70205,1146 | --------------------------------------------------------------------------- | DISCLAIMER: I don't speak for the company; they don't speak for me. :-) | --------------------------------------------------------------------------- -- --------------------------------------------------------------------------- | Bill Brown |dimenet: (513) 841-8646 | | Cincinnati Milacron Inc., Dept. 82G |uunet: uunet!dec254!brown | | 4701 Marburg Avenue |also: uunet!dec254!toolsmit |
orville@weyrich.UUCP (Orville R. Weyrich) (06/07/91)
In article <1991Jun6.125833.18549@dec254.uucp> toolsmit@dec254.uucp (Toolsmith) writes: > >People engaged in the other engineering professions also enjoy(?) the legal >status of professional certification. Anyone heard of a registered >professional software engineer? The exams for certification seem to me >to be a means for assessing the engineer's knowledge of accepted practices >in his/her discipline. > I am not a PE, and have seen the exam procedure for PE's, but there is something in the software world that may be somewhat analagous. There is an Institute for Certification of Software Professionals that offers exams and certification as follows: CDP -- Certified Data Processor (emphasis on MIS and management) CSP -- Certified Systems Professional (emphasis on A/D and S-E) CCP -- Certified Computer Programmer (emphasis on scientific or systems programming) ACP -- Associate Computer Professional (tests entry-level skills in one of several languages, such as Ada, C, FORTRAN, COBOL, Pascal) I have ACP and CSP certifications. To date, they have not gotten me a job, but there is one job that I was told I would have a better chance at if I had a CDP. Is there anyone with both a PE and one of {CDP,CSP,CCP} that would care to comment on how the two relate? The ICCP member societies include: ACM Association for Computing Machinery AIM Association for Information Management ASM Association for Systems Management AWC Association for Women in Computing CIPS Canadian Information Processing Society COMMON An IBM Computer User's Group DPMA Data Processing Management Association HKCS Hong Kong Computer Society IEEE-CS Computer Society of the IEEE ISTE International Society for Technology in Education By the way, the ICCP can be contacted at: 2200 East Devon Avenue, Suite 268 Des Plaines, IL 60018 Phone (708) 299-4227 -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
wicklund@intellistor.com (Tom Wicklund) (06/08/91)
In <1991Jun6.101639.1@happy.colorado.edu> hsrender@happy.colorado.edu writes: >In article <1991Jun6.125833.18549@dec254.uucp>, toolsmit@dec254.uucp (Toolsmith) writes: >> My point is that I think we (the software engineering community) need to >> establish some sort of program or process to define accepted practices in the >> same sense as the accepted practices of the other engineering disciplines. >> >> Anyone care to comment? >A few comments: >First, the IEEE is trying to do this (after a fashion) by establishing >guidelines and standards for various kinds of project documents (Requirements >docs, design docs, user docs, etc.) They also have standards for creating >QA plans, CM plans and test plans. Together, these go a fair way towards >defining what it is that a software engineer is supposed to know about and >do on the job. The DoD's 2167 standard also seems to have this goal in mind. Unfortunately, from what I can tell the emphasis in documentation standards (whether IEEE or DOD 2167) seems to be in generating paper in the correct format. Very often format is more important than content when documents are required. While supposed to improve software quality, they seem to do so by making it as hard as possible to make a change to allegedly working software.
warren@eecs.cs.pdx.edu (Warren Harrison) (06/08/91)
>I have ACP and CSP certifications. To date, they have not gotten me a job, >but there is one job that I was told I would have a better chance at if I >had a CDP. > >Is there anyone with both a PE and one of {CDP,CSP,CCP} that would care to >comment on how the two relate? How about a CDP and CPA? My CDP is old (I first took the exam in 1979), so they may have changed things, but one thing's for sure, back when I took it, it was all multiple choice. The CPA exam isn't, I'm not sure about teh PE exam. About the only thing you could be tested on with the CDP was terminology back then. How does the testing procedure for the CDP work now? I now it's been beefed up since 1979, but I'm not sure how. I contributed questions to the CDP exam in the early 80's and it still seemed to be multiple choice then. Warren ========================================================================== Warren Harrison warren@cs.pdx.edu Center for Software Quality Research 503/725-3108 Portland State University/CMPS
jls@netcom.COM (Jim Showalter) (06/08/91)
>Unfortunately, from what I can tell the emphasis in documentation >standards (whether IEEE or DOD 2167) seems to be in generating paper >in the correct format. Very often format is more important than >content when documents are required. While supposed to improve >software quality, they seem to do so by making it as hard as possible >to make a change to allegedly working software. You'll get no argument from me: almost all of the documentation standards I've encountered are the triumph of form over function, of style over substance, of sizzle over steak (the European HOOD standard is a notable exception). I've seen projects mired in documentation overhead to the extent that the tail wagged the dog--legitimate design improvements were weighed against their impact on the documentation, and the documentation group wound up wielding more political might than the developers! I think the emphasis on form over content is pretty easy to explain--form can be checked by people with no understanding at all of software, design, or much of anything else (after all, how hard can it be to verify that all 6-level nested paragraphs are in 12 point font?), whereas actually evaluating the CONTENT requires skill and expertise. Fortunately, for projects that have such standards inflicted on them, there is a ray of hope: much of this sort of documentation can be programmatically generated. Some might argue that this defeats the whole purpose of documentation--which, allegedly, is to produce USEFUL documentation--but so little of the documentation I've seen is actually useful that it might as well be generated automatically. Note that this ability to regenerate all of the documentation at will is a boon to those projects wishing to use a more iterative (as opposed to waterfall) style of development, since it removes the cost associated with constantly reworking the documents. I can point you to a system that generates documents automatically from Ada PDL and bubble-and-arc diagrams if you're interested. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
alan@tivoli.UUCP (Alan R. Weiss) (06/11/91)
In article <1991Jun7.171606.5862@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes: >>> >>> Anyone care to comment? > >>A few comments: > >>First, the IEEE is trying to do this (after a fashion) by establishing >>guidelines and standards for various kinds of project documents (Requirements >>docs, design docs, user docs, etc.) They also have standards for creating >>QA plans, CM plans and test plans. Together, these go a fair way towards >>defining what it is that a software engineer is supposed to know about and >>do on the job. The DoD's 2167 standard also seems to have this goal in mind. > > >Unfortunately, from what I can tell the emphasis in documentation >standards (whether IEEE or DOD 2167) seems to be in generating paper >in the correct format. Very often format is more important than >content when documents are required. While supposed to improve >software quality, they seem to do so by making it as hard as possible >to make a change to allegedly working software. Oh, I don't know ... I just used ANSI/IEEE 829-1983, "IEEE Standard for Software Test Documentation" in creating my System Test Plan. I found it to be tailorable, succinct, and not at all difficult to understand. It forced me (well, more like reminded me) to think of various aspects of testing, and most importantly my Plan was under 25 pages long and is well-organized for inspection. BTW, we're using the standard as the reference standard. (Yes, that's right: the QA/Test deliverables get inspected just like the Development deliverables. What's good for the goose ...) I do agree that MIL-SPEC 2167a and 2168 are not very useful for commercial software projects, but the ANSI/IEEE standard is great. Considering that it was developed with the input of some of Software Testing's finest minds :-) this is not surprising. _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 _______________________________________________________________________