FASE-TALK mail archive

FASE-TALK Mail Archive

Major Threads:

ACM's Withdrawal from SWEcc
Computer Science vs. Software Engineering
IEEE-CS Certified Software Engineering Professional (CSEP) Program
ACM Ubiquity Essay on Software Engineering

Hello! Don Bagert, 23 September 1997
   Re: Hello! Joe Kasser, 24 September 1997
SE Accreditation Joe Clifton, 15 October 1997
   Re: SE Accreditation Don Bagert, 16 October 1997
FASE Topic for November Don Bagert, 30 October 1997
January FASE Topic - your input needed! Don Bagert, 10 January 1998
Conference paper survey questionnaire Joe Kasser, 11 February 1998
Breaking SEE&T news Don Bagert, 18 February 1198
Texas licensing of software engineers Don Bagert, 24 February 1998
Software education across the computing field Don Bagert, 6 March 1998
PhD programs in software engineering Don Bagert, 8 April 1998
FASE topic: your input neededDon Bagert, 10 May 1998
FASE breaking news: Texas Board recognizes SE officially Don Bagert, 17 June 1998
Reviewers for software engineering book Eric Braude, 25 June 1998
   RE: Reviewers for software engineering book Jurgen Borstler, 29 June 1998
Reminder: FASE Issue on Education and Licensing Don Bagert, 28 June 1998
Texas Board - application date correction Don Bagert, 30 June 1998
Company-based certificationDon Bagert, 14 February 1999
   Company-based certificates Mike McCracken, 15 February 1999
   Company-based certificates Laurie Werth, 15 February 1999
Growth of Software Engineering Education 15 March 1999
[Q:] Journal(s) on Software Engineering Education Jurgen Borstler, 29 July 1999
teaching software processTom Horton, 15 November 1999
    Re: teaching software process Gastón Mousqués, 16 November 1999
    Re: teaching software process David Alex Lamb 24 November 1999

ACM's Withdrawal from SWEcc

ACM's Withdrawal from SWEcc Don Bagert 15 July 2000
   Re: ACM's Withdrawal from SWEcc Paul E. MacNeil 18 July 2000
   Re: ACM's Withdrawal from SWEcc Chris Starr 18 July 2000
   Re: ACM's Withdrawal from SWEcc Robert Seletsky 18 July 2000
   Re: ACM's Withdrawal from SWEcc Steve Merrick 19 July 2000
   Re: ACM's Withdrawal from SWEcc Kari.Hoijarvi 19 July 2000
   Re: ACM's Withdrawal from SWEcc Anthony J. Duben19 July 2000
   Re: ACM's Withdrawal from SWEcc Dennis K. Peters 19 July 2000
   Re: ACM's Withdrawal from SWEcc Norm Gibbs 19 July 2000
   Re: ACM's Withdrawal from SWEcc Tim Lethbridge 19 July 2000
   Re: ACM's Withdrawal from SWEcc Steve Merrick 19 July 2000
   Re: ACM's Withdrawal from SWEcc Tim Lethbridge19 July 2000
   Re: FASE Talk Discussion of ACM/SWEcc Dennis Frailey 28 August 2000
End of Thread on ACM's Withdrawal from SWEcc

Achieving a World-Wide Software Engineering Profession Helen Edwards 20 September 2000
SIGCSE Doctoral Consortium Vicki Almstrum 11 November 2000
Re: FASE Volume 10 Number 11 November 2000 Cem Kaner 17 November 2000

ACM Ubiquity Essay on Software Engineering

Essay on SW Engineering Vicki L. Almstrum 23 October 2001
   Re: Essay on SW Engineering Paul E. MacNeil 23 October 2001
   Re: Essay on SW Engineering Laurie Werth 23 October 2001
   Re: Essay on SW Engineering Dennis J. Frailey 23 October 2001
   Re: Essay on SW Engineering David W. Hensley 24 October 2001
   Re: Essay on SW Engineering Paul E. MacNeil 24 October 2001
   Re: Essay on SW Engineering Brent Capps 24 October 2001
   Re: Essay on SW Engineering David Luginbuhl 24 October 2001
   Re: Essay on SW Engineering Mike McCracken 24 October 2001
   SE Practice and SE Education Paul E. MacNeil 24 October 2001
   Re: Essay on SW Engineering Steve Tockey 24 October 2001
   Re: Essay on SW EngineeringDennis J. Frailey 25 October 2001
End of Thread on ACM Ubiquity Essay on Software Engineering

Subject: Hello!
Date: Tue, 23 Sep 1997 23:41:04 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

There are currently 18 subscribers to fase-talk, which will hopefully
grow over time.

I will start with a very generic question: what do you think should be
the direction of FASE? Do you think that the addition of a monthly
discussion topic is useful? What else should we add/delete?

I look forward to hearing your comments on this and other issues.

Thanks,

Don Bagert
FASE co-editor

Subject: Re: Hello!
Date: Wed, 24 Sep 1997 09:50:17 -0500
From: Joseph Kasser <jkasser@UCSFS1.UMUC.EDU>
Reply-To: FASE-TALK <FASE-TALK@CPM211-1.CS.TTU.EDU>
Organization: UMUC
To: FASE-TALK@CPM211-1.CS.TTU.EDU

Let me suggest a topic. I'm updating a sylabus for a graduate class
on software maintennance.

I'm looking into adding cmm, iso 12207, 9000-3, problems with and
solutions to transitioning existing systems, year 2000 etc. There
does not seem to be a suitable text book for the class.

I'm interested in discussing the topics others think should be
covered in the class, and any suitable published material on same.

Joe

> There are currently 18 subscribers to fase-talk, which will
hopefully
> grow over time.
>
> I will start with a very generic question: what do you think should be
> the direction of FASE? Do you think that the addition of a monthly
> discussion topic is useful? What else should we add/delete?
>
> I look forward to hearing your comments on this and other issues.
>
> Thanks,
>
> Don Bagert
> FASE co-editor
>
======================================================
Joe Kasser                                    Organizational Engineering
University of Maryland University College           The Excellence! Paradigm
Reply to:                                   The key to the 21 century
jkasser@polaris.umuc.edu
office phone 301 985 4616
======================================================

Subject: SE Accreditation
Date: Wed, 15 Oct 1997 14:02:37 -0500
From: clifton <clifton@AM.UWPLATT.EDU>
Reply-To: Title of sample LISTSERV list <FASE-TALK@CPM211-1.CS.TTU.EDU>
To: FASE-TALK@CPM211-1.CS.TTU.EDU

I know that IEEE is working on the accreditation
details for Software Engineering programs.

I heard a rumor that it could be out as early as next year.

Is anyone on this list on that IEEE committee?
Has anyone heard any leaks of what they will come up with?

-Joe Clifton
University of Wisconsin - Platteville

Subject: Re: SE Accreditation
Date: Thu, 16 Oct 1997 23:14:17 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

Check out FASE, Volume 7 Number 01 (August 15, 1997) - available at the
FASE web page (http://www.cs.ttu.edu) for a report concerning an article
on the subject. This is pretty much all I know at this time.

Don Bagert
bagert@ttu.edu

clifton wrote:

> I know that IEEE is working on the accreditation
> details for Software Engineering programs.
>
> I heard a rumor that it could be out as early as next year.
>
> Is anyone on this list on that IEEE committee?
> Has anyone heard any leaks of what they will come up with?
>
> -Joe Clifton
> University of Wisconsin - Platteville

Subject: FASE topic for November
Date: Thu, 30 Oct 1997 21:13:35 -0600
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

The topic for the November issue of FASE will be graduate school
opportunities. I invite each of you on the fase-talk listserv to
respond to the following question:

"What advice would you give to a prospective graduate student who wishes
to specialize in software engineering?"

The intention here is supply some information and ideas which can be
passed on to the students and co-workers of FASE subscribers. There is
a lot of leeway intentionally given here, and several open questions.
(For instance, is the prospective student interested in a Master's
thesis, a Master's non-thesis, or a PhD? Does the prospective student
need any work experience? need a CS undergraduate degree? Should it be
a software engineering degree program, or can it just be a CS program
with an SE track?)

Your response can be in any length from a paragraph to a couple of
pages, depending how much time you have, and whatever you feel is
appropriate.

Please send any contributions to the listserv
(fase-talk@cpm211-1.cs.ttu.edu) or to me (bagert@ttu.edu) by November
13.

I look forward to hearing from you. Thank you for your time and
attention.

Don Bagert
FASE Academic Editor
bagert@ttu.edu
http://www.cs.ttu.edu/fase

Subject: January FASE topic - your input needed!
Date: Sat, 10 Jan 1998 13:01:36 -0600
From: Don Bagert <bagert@ttu.edu>
To: edwork@sei.cmu.edu, fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

(My apologies in advance if you get a duplicate posting.)

I just wanted to remind you about the January FASE topic (reprinted
below). If you can get your answers to me by Wednesday the 14th, I
would appreciate it, since I will be out of town most of the 15th
because of another meeting involving the Texas State Board (which will
be a "late bulletin" for the January issue); therefore, I will have to
get most of the issue ready before I leave.

Thanks,

Don Bagert
FASE co-editor
bagert@ttu.edu
________________

Next Month's Topic: Predictions for SEE&T in 1998 - YOUR INPUT
REQUESTED!!!

The previously-announced topic of Distance Education for the January
1998 issue has
been indefinitely postponed. In its place, the subject will be
"Predictions for
1998", and consist of two questions for you:

1. What do you forsee for the software engineering education and
training fields in 1998?

2. What are your "New Year's Resolutions" for your personal
   involvement for software engineering education and training for
   1998? (Or, to put it in another way for those cultures that don't
   have the tradition of New Year's resolutions, "What would you like
   to do in software engineering education and training in 1998 that
   you were not able to this past year?"

We really want to hear from you on this!! Send your answers to Don
Bagert
(bagert@ttu.edu). Thanks!

Subject: Conference paper survey questionaire
Date: Wed, 11 Feb 1998 15:53:54 -0500
From: Joseph Kasser <jkasser@UCSFS1.UMUC.EDU>
Reply-To: FASE-TALK <FASE-TALK@CPM211-1.CS.TTU.EDU>
Organization: UMUC
To: FASE-TALK@CPM211-1.CS.TTU.EDU

Dear colleague

This is to request a moment of your time to assist in providing data
for a conference paper. The paper analyzes some reasons why projects
fail (cancelled, or go over buget and schedule). Would you please show
if you agree or disagree with the following reasons for project
failure? Just write an "A" or a "D" in the appropriate column below
agree/disagree. If you have no opinion on the reason, please leave it
blank.

I will send all respondents a copy of the final paper. The paper will
be send to the E-mail address originating your response

Agree/Disagree Reason

   Poor requirements
   Failure to use experienced people
   Failure to use Independent Verification and Validation (IV&V)
   Lack of process and Standards
   Lack of, or, poor plans
   Failure to validate original specification and requirements
   Lack of Configuration Management
   Low morale
   Management does not understand SDLC
   Management that does not understand technical issues
   No single person accountable/responsible for project
   Client and development staff fail to attend scheduled meetings
   Coding from high level requirements without design
   Documentation is not produced
   Failure to collect performance and process metrics and report them
      to management
   Failure to communicate with the customer
   Failure to consider existing relationships when replacing systems
   Failure to reuse code
   Failure to stress test the software
   Failure to use problem language
   High staff turnover
   Key activities are discontinued
   Lack of Requirements Traceability Matrix
   Lack of clearly defined organizational (responsibility and
      accountability) structure
   Lack of management support
   Lack of priorities
   Lack of understanding that demo software is only good for demos
   Management expects a CASE Tool to be a silver bullet
   Political considerations outweigh technical factors
   Resources are not allocated well
The Quality Assurance Team is not responsible for the quality of
       the software
There are too many people working   on the project
Unrealistic deadlines - hence schedule slips
Hostility between developer and IV&V
Other (please write in here)

Now please tell me about yourself

management __ years of experience ____
non-management __ years of experience ___

Background
systems engineering __
software engineering __
hardware engineering __

Please identify up to seven items in the list which you feel are the
most important and list them in in order of priority. Note 1 is the
item with highest priority, 7 is the item with the lowest priority.

Please list them below, or write the number next to the
appropriate item in the above list

1
2
3
4
5
6
7

Thankyou for your time

Joe Kasser

PS. If you know of any distribution lists on the topics of software
engineering, systems engineering and project management, please
forward this survey questionaire appropriately.

Subject: breaking SEE&T news
Date: Wed, 18 Feb 1998 00:11:19 -0600
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

I thought that I would occassionally place "breaking news" in software
engineering education and training here in FASE-TALK occassionally, if
that's ok with everyone. For instance, the Texas State Board of
Professional Engineers will be meeting on software engineering tomorrow
(Wednesday), and *big news* may be coming from it. I hate to wait
until March 15, when FASE is next published...

Don

Subject:Texas licensing of software engineers
Date: Tue, 24 Feb 1998 17:43:06 -0600
From: Don Bagert <bagert@hub.ofthe.net>
Reply-To: bagert@ttu.edu
To: SIGCSE.MEMBERS@acm.org, fase-talk <fase-talk@cpm211-1.cs.ttu.edu>, edwork@sei.cmu.edu

[My apologies in advance for duplicate postings.]

This message recently arrived from Dave Dorchester, chair of the
Licensing Committee of the Texas State Board of Professional Engineers,
concerning their meeting of 18 February 1998. (The Board is empowered
by the State of Texas to regulate the licensing of professional
engineers within its boundaries.)

"At today's State Board meeting the Board unanimously voted to approve
the following statement: 'The Board officially recognizes the
discipline of Software Engineering as having a sufficicently distinct knowledge
base to allow licensing for engineers experienced in that knowledge base.
Further the Board will move forward with the development of rules to
implement this intent, and support all state and national efforts to
develop accredited educational programs and professional examinations.'

"Under state rules this is now a proposal that will be published in the
Texas Register for public comment and at the June meeting can be voted
on for final approval."

What this means is that unless something very unusual happens between
now and June, Texas will become the first state in the U.S. to
officially recognize software engineering as a professional engineering
discipline, and the first to license professional engineers in the
area of software engineering.

Articles concerning previous meetings of Texas State Board committees
that addressed the issue of software engineering can be found in the
December 1997 and January 1998 issues of the FASE electronic newsletter
(http://www.cs.ttu.edu/fase); an update will be filed in the March
issue.

If you have any questions, please feel free to contact me.

Don Bagert
Associate Professor of Computer Science
Texas Tech University
bagert@ttu.edu

Subject: software education across the computing field
Date: Fri, 06 Mar 1998 08:12:03 -0600
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

I want to invite you to make a submission for the FASE March issue,
whose topic is "software education across the computing field".

You might want to look at
http://www.cs.ttu.edu/dept/people/faculty_staff/bagert/se2000.htm for
an idea of the general concept of "software education" (at least, as
far as how I define it). A contribution can be of pretty much any
length, but I would suggest anywhere from a paragraph to a couple of
pages.

Please make any submissions in ASCII format, with 70 characters maximum
per line. Submissions are due by March 13.

I hope that you'll be able to contribute.

Don Bagert
FASE co-editor

Subject: PhD programs in software engineering
Date: Wed, 08 Apr 1998 13:33:57 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

There are currently no PhD programs in software engineering anywhere in
the world. However, in the United States many states (such as Texas)
have laws that specify that only licensed professional engineers (PEs),
or "engineers-in-training", can teach in accredited engineering
programs. In states that require their engineering professors to be
PEs, there is often an "academic" method available for obtaining PE
status. For instance, in Texas, if a person gets a PhD in an
engineering discipline at an institution which has an accredited
Bachelor's or Master's degree program, they can teach as a faculty
member in an accredited engineering program. For the first six years,
they are considered more-or-less as an "engineer-in-training", and then
after that, are eligible to become a licensed professional engineer.

Since software engineering programs in the U.S. will start to be
accredited soon (most of them initially at the Master's level),
licensed PEs will be needed to teach in those programs in many states.
Now, I assume that there will probably be some type of "grace period"
by which faculty will not need to be PEs to teach in a software
engineering degree program, but that period won't be forever. Which
means that we need to have PhD programs in software enginering, or have
faculty with PhD in other engineering disciplines doing all of the
teaching of software engineering.

Here's where the problem comes in: at in least in Texas, and I expect
in other states, there is an increasing emphasis on undergraduate
education, and it's becoming harder and harder to get new PhD programs
approved. So the spread of PhD programs in software engineering will
likely not be nearly as fast as those in CS in the 1960's and 1970's.
Which means that something has to give.

I like to hear your opinions on what you think might happen, and what
should ideally happen as far as PhD programs in software engineering
are concerned. (I realize that one possible answer is "we shouldn't
have them" =)

Thanks in advance for your input.

Don Bagert
Associate Professor of Computer Science
Texas Tech University
bagert@ttu.edu

Subject: FASE topic: your input needed
Date: Sun, 10 May 1998 19:41:29 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

The May 1998 issue of FASE will be its 100th. The topic for that issue
is titled "FASE: Past and Future". Besides looking at some of the
highlights of the first 100 issues of FASE, this article will look at
the possibilities and predictions for the future. Also, the past and
potential futures of publication in the software engineering
education and training field will also be examined.

I would like to hear from you on these subjects. In particular, I'd
like for you to address any or all of the following questions:

1. What are your thoughts and memories (good and bad) about FASE as it
reaches issue 100?

2. What's your opinion about the past and current state of software
engineering education and training publication? (e.g. journals,
proceedings, newsletters, special issues, books, technical reports)

3. What do you see FASE evolving into over the next several years?

4. What's your opinion on the future of software engineering education
and training publication?

Please send your reminisces, historical facts, predictions, and
opinions to me at bagert@ttu.edu by May 14. Thanks!

Subject: FASE breaking news: Texas Board recognizes SE officially
Date: Wed, 17 Jun 1998 23:31:13 -0500
From: Don Bagert <bagert@hub.ofthe.net>
Reply-To: bagert@ttu.edu
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

[My apologies in advance for duplicate postings.]

This is a update of an email sent out to several sources on the
Internet, following a vote by the Texas Board of Professional Engineers
on 18 February 1998, which stated the Board's intention to recognize
software engineering as a legitimate engineering discipline, and to
license professional engineers in that area. A complete position
statement from the Texas Board can be found at
http://www.main.org/peboard/softweng.htm. As expected, on June 17 the
Texas Board gave unanimous approval to all proposals found in this
statement. In 20 days, the Texas Board will be able to begin licensing
software engineers, although initially this will be only through a
waiver process, until examinations are in place (probably in one year).

Please let me know if you have any questions.

Don Bagert
Associate Professor of Computer Science
Texas Tech University
bagert@ttu.edu

Subject: Reviewers for software engineering book
Date: Thu, 25 Jun 1998 14:10:35 -0500
From: Eric Braude <ebraude@UISM.BU.EDU>
Reply-To: FASE-TALK <FASE-TALK@CPM211-1.CS.TTU.EDU>
To: FASE-TALK@CPM211-1.CS.TTU.EDU

     I am writing a textbook tentatively titled "Software Engineering: an
     Object-Oriented Perspective", to be published by Wiley next year. We
     would appreciate reviews from the community. Please contact me if you
     are interested, and I will put you in touch with my editor, Regina
     Brooks, or contact her directly at rbrooks@wiley.com

In any case, I'd appreciate very much any thoughts members may have on
what such a textbook should be like.

-- Eric Braude
Boston University

Subject: Re: Reviewers for software engineering book
Date: Mon, 29 Jun 1998 09:21:20 +0200
From: Jurgen Borstler <jubo@CS.UMU.SE>
Reply-To: FASE-TALK <FASE-TALK@CPM211-1.CS.TTU.EDU>
To: FASE-TALK@CPM211-1.CS.TTU.EDU

Interesting. Is contents of the book already fixed? I teach Software
Engineering (traditional and OO) mainly using a project based
approach. We are still looking for a single textbook fitting our OO
course (please check http://www.cs.umu.se/tdb/kurser/TDBC18/ for some
information on the OO course).

Best Regards,
              jubo
------------------------------------------------------------------------
Dr. Jürgen Börstler                             phone: +46 (90) 786-6735
Department of Computing Science                   fax: +46 (90) 786-6126
Umeå University                                   e-mail: jubo@cs.umu.se
SE-901 87 Umeå, SWEDEN                 URL: http://www.cs.umu.se/~jubo/

Eric Braude writes:
>      I am writing a textbook tentatively titled "Software Engineering: an
>      Object-Oriented Perspective", to be published by Wiley next year. We
>      would appreciate reviews from the community. Please contact me if you
>      are interested, and I will put you in touch with my editor, Regina
>      Brooks, or contact her directly at rbrooks@wiley.com
>
>      In any case, I'd appreciate very much any thoughts members may have on
>      what such a textbook should be like.
>
>         -- Eric Braude
>         Boston University
>

Subject: Reminder: FASE issue on Education and Licensing
Date: Sun, 28 Jun 1998 16:24:18 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

[My apologies in advance for duplicate postings.]

Call for Position Statements

FASE (Forum for Advancing Software engineering Education) - electronic
newsletter (http://www.cs.ttu.edu/fase)

July 1998 Topic: Licensing of Professional Engineers in Software
Engineering

Very few countries currently license software engineers. As has been
reported in various electronic media over the last several months,
Texas has been planning to license professional engineers (PEs) in
software engineering, with the final, unanimous vote in favor having
come on 17 June 1998. (See http://www.main.org/peboard/sofupdt.htm for
the latest details.) It is expected that the rest of the United States
will follow suit soon thereafter.

Licensing of software engineers by a governmental unit has an obvious
impact on the higher education of students who plan to pursue a
license. For instance, in the United States, it is much easier to
obtain a PE license if one has a degree from a program accredited by
ABET (Accreditation Board for Engineering and Technology). As reported
in previous issues of FASE and elsewhere, ABET is considering program
criteria for accrediting software engineering programs.

Another issue involves the fact that computer science programs
accredited by the Computer Sciences Accreditation Board (CSAB) may
eventually be considered equivalent to an ABET-approved degree for the
purposes of licensing. (The new guidelines in Texas place CSAB
accreditation below ABET, with four more years of experience required
for the former.)

Finally, the morning session of the Fundamentals of Engineering (FE)
exam, which is given in the United States to engineering students
around the time of their graduation, includes section on topics such as
statics, thermodynamics, and materials. (The nature of the morning
section may change because of the inclusion of software engineering as
one of the disciplines; for instance, there may be additional sections
on the exam, and the student picks X out of Y parts of the exam to
take. However, nothing has yet been decided on this issue.)

Position statements on the issue of education of students who
potentially could be licensed as software engineers are requested. The
position statements can be as short as a paragraph or as long as 203
pages.

Some of the questions that could be addressed in your position
statement are:

1. How much should a software engineering curriculum be affected by a
licensing exit exam such as the FE?

2. (a) How will software engineering programs (and the potential for
new programs) be affected if accredited computer science programs are
considered equivalent educational background?
(b) If CS students are allowed to take the same exit exam for
engineer licensing as SE students, should the exam be SE-oriented,
CS-oriented, or a combination?
(c) How much should the computer science curriculum be affected by
such an exit exam?

Although the licensing issue is currently of special interest to the
United States, due to ongoing events, people from outside of the U.S.
are also encouraged to share their thoughts on these issues as they
relate to education and licensing in their respective countries.

Please send any position statements to Don Bagert at bagert@ttu.edu no
later than July 8.

Using the following guidelines for submission is encouraged: ASCII
format, with no more than 70 characters per line (71 including the new
line character). This 70-character/line format should be viewable in a
text editor such as Microsoft Notepad WITHOUT using a "word wrap"
facility. All characters (outside of the newline) should in the ASCII
code range from 32 to 126 (i.e. "printable" in DOS text mode).

Thank you for your time and consideration.

Subject: Texas Board - application date correction
Date: Tue, 30 Jun 1998 09:40:50 -0500
From: Don Bagert <bagert@ttu.edu>
To: fase-talk <fase-talk@cpm211-1.cs.ttu.edu>

[My apologies in advance for duplicate postings.]

Dave Dorchester (Chair of the Licensing Committee of the Texas Board of
Professional Engineers) asked me to pass along the fact that
applications for a professional engineering license in the branch of
software engineering (see previous note below) will not actually be
accepted until 20 days after the guidelines are published, which will be
on August 1. Previously, I had mistakenly thought that it was 20 days
after the affirmative vote on June 17.

"Unfortunately, applications received before [August 1, 1998] must be
returned without being processed." (from
http://www.main.org/peboard/sofupdt.htm)

I apologize for unknowingly providing you with inaccurate information.

Sincerely,

Don Bagert
bagert@ttu.edu
___

Please let me know if you have any questions.

Don Bagert
Associate Professor of Computer Science
Texas Tech University
bagert@ttu.edu

Subject: company-based certification
Date: Sun, 14 Feb 1999 12:51:30 -0600
From: Don Bagert <bagert@ttu.edu>
To: fase-talk@listserv.ttu.edu

Hello, FASE-TALK subscribers. I know that this list has been quiet
for some time, but I hope that it will be used with more frequency
in the future.

I would like to discuss the recent rash of certification programs
that have popped up across the country. I am not talking about
ICCP, which has existed for many years, and gives more of a general
CS certification exam, but those programs that are tied to a specific
company, the most well-known and popular of these being "Microsoft
Certified System Engineer" (MCSE).

The impression that I am increasing getting is that teenagers are
getting the impression that either 1) programs such as MCSE will allow
them to get some college credit in computer science, or 2) that they
can skip college altogether and just get the proper certifications,
which can propel them into a successful computer career. Both
suppositions are, of course, incorrect; I don't know of any four-year
college that will give regular credit for passing such programs, and
while bypassing college may provide a paying job in the short term,
they will likely need a Bachelor's degree to have a long, successful
career in the industry.

These certification programs are unfortunately finding their way
into the educational mainstream. For instance, some universities
(even those with a College of Engineering!) are offering an MCSE
course as part of their continuing education program, and our local
school district recently announced that they would offer a number
of high school courses that would lead to certification, including
the MCSE.

As implied from above, a particular concern with the MCSE program is
the use of the term "engineer"; even though the term used is "system
engineer", the program is software-based. My understanding in hearing
an explanation from the Executive Director of the Texas Board of
Professional Engineers is that it is not illegal to sell MCSE
materials in Texas, but it is illegal to call yourself a Microsoft
Certified System Engineer and offer software engineering (or
equivalent) services to member(s) of the public in that state.

With all this in mind, I'm very concerned about this situation,
especially since the number of people taking MCSE and other similar
certification programs, and the public's acceptance as a substitute
for a college education, appears to be rising at an alarming rate.

I'd like to hear your opinions on the subject.

Don Bagert
FASE Co-Editor
bagert@ttu.edu

P.S. Anyone subscribing to the FASE-TALK listserv should be able to
send a message to the list using fase-talk@listserv.ttu.edu.
Please feel free to start your own discussions on this list. If you
have any problems with sending mail to the listserv address, please
contact me.

Subject: Company based certificates.
Date: Mon, 15 Feb 1999 10:55:09 -0500
From: Mike McCracken <mike@cc.gatech.edu>
To: fase-talk@ttacs6.ttu.edu

In response to Don's questions here are some things I have been worrying over.
1. For the moment, forget the inappropriate use of descriptors (such as
engineer, etc), and think about the content of the material being offered
in high schools and trade schools.
2. If I were a young sport, interested in computing, and not inclined to
go to college, what options do I have? Historically, that person could
enter some type of trade program in their high school and become a
machinist, or a technician of some sort, or whatever. The programs were
obviously oriented around models of training, but these folks were able to
have careers in the trades.   The types of programs Don described may be
filling that niche.
3. With the dumming up of the University system it seems that to get a
secretarial job these days you need to have a bs (generally folks who get a
degree in an area that is in low demand), or worse get a bs at a school
that is so bad that all you can get is a clerical job.   This little soap
box is based on my personal issue of society deciding that everyone needs a
college education to be employable.
4. I think the model that Don is describing is an indirect reversion to
the trade school model. That is, attain enough knowledge and skill to get
a technical job without having to go to College. A term I use to describe
this is, information technicians.
5. I personally think it is a good idea, and I suspect (haven't done the
surveys) that industry needs these types of people along with their college
grads.
6. I agree with Don that over-advertising and possibly implying that the
certificates are transferable into an academic program or at least
equivalent to a College degree is not right. The point is more of truth in
advertising.   Some of you may be old enough to remember the advertising in
match books to learn various trades through mail order courses.
Lots of other things come to mind, but I'll stop here for the moment.
Mike

Subject: Company based certificates
Date: Mon, 15 Feb 1999 12:58:47 -0600
From: Laurie Werth <lwerth@cs.utexas.edu>
To: fase-talk@ttacs6.ttu.edu
CC: lwerth@cs.utexas.edu

Mike makes a good point about the high school grads who don't want to
go to college. A more serious problem is the increasing number who
don't even finish high school - the prospect of good jobs would help
a few of them stay in school to get reasonable training.

I have three points:

1.      One of my objections to the certificate programs is the high
        cost. At $2000-$10,000 each, they are a big profit center for
        the companies - with no pressure to see that students actually
        complete the training once they have paid.

        This is not a new problem. One of the popular match cover
        programs promised that you too could could be a programmer -
        for $1000 (at lot of money 20 years ago) you received a
        flowchart template, a little book, and the opportunity to
        mailed in a few FORTRAN programming efforts to be graded.

        Don't know if they still have the federal grants to cover
        training, but there were many rip-off programs which had
        only to say that students were qualified and get them to
        sign a loan agreement - some offered stereos etc. as
        incentives. The training might have included learning to
        run the old card sorters etc. but having gotten their money
        there was little motivation to teach anything.

2.      One thing that would help would be public education.
        The licensing effort will provide some publicity - we hope.
        Just having various curriculum tracks laid out for two year,
        undergraduate and several varieties of MS programs with
        Continuing Education can be enlightening. The web is an
        obvious place for this.

        There are beginning to be a number of Distance Learning/
        Continuing Education programs offered over the web. I'm
        trying to get some of these on my Computer and Professional
        Ethics web site: www.cs.utexas.edu/users/ethics/

3.      Chip companies in Austin are desparate for workers to make
        chips - the groceries can't even hire bag boys due to the
        very attractive positions available. They work with the
        Community Colleges to develop training for potential workers.
        The Community Colleges also provide beginning classes in
        programming etc. which has enabled some bright folks get
        a start - if only to work on Y2K problems.

I would appreciate any comments and suggestions.

Laurie Honour Werth
Department of Computer Sciences
The University of Texas at Austin
Austin, TX 78712-1188

Phone: 512-471-9535
Fax: 512-471-8885
email: lwerth@cs.utexas.edu

Subject: Growth of Software Engineering Education
Date: Mon, 15 Mar 1999 11:08:50 -0600
From: Don Bagert <bagert@ttu.edu>
To: fase-talk@listserv.ttu.edu

Something that has interested me over the last year is the growth of
software engineering education, or (possibly) the lack of it. While we
see a number of initiatives related to Software Engineering as a
Profession (e.g. the SWECC), have seen two groups working on software
engineering undergraduate curriculum issues, and in the United States
have seen accreditation guidelines approved, we haven't seen the
groundswell of interest in software engineering education. Two cases
in point: the attendance at CSEE&T has been about the same for the past
few years, and FASE subscriptions have only gone up slightly since
there was a large increase in March 1998. (Note: a number of expired
email addresses are being deleted from the subscriber list for the next
issue, so the February 1999 subscription number is inflated.)

In the U.S., there has been more interest in software engineering at
the Frontiers in Education conference, but there has not been much of
an increase in the number of undergraduate and graduate software
engineering programs. There do seem to be more ads for computer
science and engineering faculty asking for applications in the area of
software engineering; however, as a person from one of those schools,
there are not many applicants to choose from.

So here are my questions: will we eventually see a large growth in
software engineering degree and specialty programs? Is the apparent
lack of growth in such programs real, and if so, is it due to lack of
interest, or to a lack to qualified faculty? If faculty is the
problem, would Ph.D. programs in software engineering be of any help?
(An aside: I have seen several faculty ads recently looking for a Ph.D.
in "computer science or software engineering", despite the fact that
the only SE doctoral program I have ever heard of is with a consortium
of schools in France.) Is all of this roughly the same as for computer
science in the mid-1960's, right before ACM Curriculum '68 came out?

As always, I'll be interested in hearing your thoughts.

Don

Subject: [Q:] Journal(s) on Software Engineering Education
Date: Thu, 29 Jul 1999 15:04:55 +0200 (MET DST)
From: Jurgen Borstler <jubo@cs.umu.se>
To: fase-talk@ttacs6.ttu.edu

Dear Colleagues,

do you know of any international *refereed* Journal(s) on Software
Engineering Education? If so how do you rate them?

   o SIGCSE Bulletin occasionally publishes refereed articles,
     but is oriented towards Computer Science Education in general.
     For more information see
        http://www.acm.org/sigcse/bulletin/

   o Computer Science Education is oriented towards Computer Science
     Education in general and publishes articles on Software
     Engineering Education more or less regularly.
     For more information see
        http://www.swets.nl/sps/journals/cse1.html

   o IEEE Transactions on Education is oriented towards Endineering
     Education in general and rarely publishes articles on Software
     Engineering Education. Articles on Computer Science Education are
     published regularly. Has a very long back-log.
     For more information see
        http://www.ieee.org/organizations/pubs/pub_preview/e_toc.html

In case I receive enough input, I'll post a summary of the material.

Thanks for your help,
                      jubo
------------------------------------------------------------------------
Dr. Jürgen Börstler                             phone: +46 (90) 786-6735
Department of Computing Science                   fax: +46 (90) 786-6126
Umeå University                                   e-mail: jubo@cs.umu.se
SE-901 87 Umeå, SWEDEN                  URL: http://www.cs.umu.se/~jubo/

Subject: teaching software process
Date: Mon, 15 Nov 1999 18:29:43 -0500 (EST)
From: Tom Horton <tom@cse.fau.edu>
To: FASE-Talk List <FASE-TALK@ttacs6.ttu.edu>

Hello. I'm am actively trying to develop better ways of teaching
undergraduate students in software engineering courses about using a
planned and documented software development process.

I'm particularly interested in doing this in two ways:

a) Developing support materials that can be used in a usual SW Engin.
     survey course. Such materials might include a description of the
     activities and deliverables for "lite" process, together with
     templates and examples of documents and other development products.
     Students in this course might simply study these, or be asked to do
     exercises based on these.

b) Using this "lite" process in a project-oriented course where students
     work in teams on a semester-long development project. In this course
     students would be expected to follow the process and create
     development products according to the process.

QUESTION 1: If you're doing anything like this in a software engineering
course, or if you're teaching a project course where a process is defined
and followed, please email me and let me know what you're doing. I'm
particularly interested in seeing samples or templates of things like
Quality Assurance Plans, Design documents, etc.

QUESTION 2: I would be interested in participating in (or organizing) a
Birds of a Feather group at SIGCSE 2000 on teaching software process or
software engineering project courses. If you've already proposed
something like this, or if you're interested in joining in if I set one
up, please get in touch.

BTW, I am aware of the process defined as part of CMU's Studio, but think
we need something simpler for undergraduate courses. I'm also aware of
Humphrey's work in this area, including the recent TSPi book. But again,
I think (for now) that this is pretty intense and "large" to be
incorporated into most undergraduate courses without making a major course
redesign. I know others will feel different, but that's my conclusion
after teaching project-centered courses here at FAU and at the Univ. of
Virginia last spring.

I'll summarize responses back to the list, if there are enough. I am also
cross-posting this to both the SIGCSE and FASE-Talk email lists, so I'll
gather replies from each and summarize to both.

Looking forward to hearing from others with similar interests. Thanks!

Tom Horton

-------------------------------------------------------------------------
Dr. Thomas B. Horton, Associate Professor
Dept. of Computer Science and Engineering, Florida Atlantic University
Boca Raton, FL 33431 USA Phone: 561/297-2674 FAX: 561/297-2800
Internet: tom@cse.fau.edu WWW: http://www.cse.fau.edu/~tom

Subject:

Subject: Re: teaching software process
Date: Tue, 16 Nov 1999 19:21:24 -0300
From: Gastón Mousqués <mousques@adinet.com.uy>
Reply-To: mousques@athenea.ort.edu.uy
To: FASE-Talk List <FASE-TALK@ttacs6.ttu.edu>

Tom, first of all I have to apology for my English, but I don't
usually write in English.

At our school we have a capstone project of six months duration
in which the students work on projects following a documented
process.

We started this experience six years ago. At the beginning, we
only had a few activities described and templates for a few key
documents and standards. Now we have a process that includes
several manuals for different processes (SQA, SCM, Project
Management, Development, etc), and templates for all the
artifacts created during the development process.
We have a process group lead by one of our instructors that each
semester works with 3 or 4 students on documenting and
improving the process. Each semester, this group has the task of
formalizing some activities of the process that were previously
done informally, or that we think needs to be improved.

I will try to describe briefly the way we work.

At the beginning of the semester we make a call for "project
ideas" in which students can bring a description of a project they
want to work on. The conditions are that the project should have a
person that can act as a user, and that it should have a reasonable
complexity. We also have development agreements with local
companies that provide us with projects and they act as clients
and users.

After selecting the candidate projects we present them to the
students, and ask them to form a development group of 4 to 8
students, and to choose the project they want to work on.

During the first month we have a period of training in which we
teach short courses on topics like requirements engineering,
project management, design, tools, etc. The goal of these courses
is to review the main software engineering topics covered during
the previous semester's courses and to get the students
acquainted with the process.

After this period of training each group must adapt the process to
the project they are going to work on; they must choose and
justify which roles and practices of the ones prescribed by the
process they are going to follow.

Once the projects are set, we assign an instructor to each group
that acts as a mentor that helps the students with the problems
they have while working on the project.
As an additional level of assistance to the students, we have what
we call Role Mentors (Manager, Architect, SQA, Design.). The
role mentor meets weekly with all the students that are
performing a specific role to discuss problems and to study
different practices they must use.

I know that from this description our process might look
heavyweight, but we make real emphasis on having each group
adapt the process to their project needs. Also, it may look that we
have a large group of instructors, but our staff is of 4 role mentors
and 3 or 4 group mentors (all working part-time). Each semester
we work with 25 or 40 students (this is one of the advantages of
working with a process we can repeat).

The experience so far has been very good, especially because
students learn how to work under a process, they face the
problems of working on groups, and they apply SE practices on a
real project with real pressures. Each semester we make student
surveys on the experience, and we also try to get feedback from
the student's employers once they are hired.

But there are also some drawbacks. For some projects 6 month is
not enough time to cover the full life cycle and at the same time to
learn how to apply SE practices. Sometimes is difficult to select
projects complex enough to effectively apply SE practices during a
time span of 6 month. Next year, under our new plan of study, we
will extend the projects to one year.
Another drawback is that students specialize on one or two roles
and they don't get to know in depth the activities performed by
other members.

I hope our experience helps,

---------------------------
Gastón Mousqués
Cátedra de Ingeniería de Software
Facultad de Ingeniería
Universidad ORT Uruguay

Date sent:              Mon, 15 Nov 1999 18:29:43 -0500 (EST)
From:                   Tom Horton <tom@cse.fau.edu>
Send reply to:          Tom Horton <tom@cse.fau.edu>
To:                     FASE-Talk List <FASE-TALK@ttacs6.ttu.edu>
Subject:                teaching software process

> Hello. I'm am actively trying to develop better ways of teaching
> undergraduate students in software engineering courses about using a
> planned and documented software development process.
>
> I'm particularly interested in doing this in two ways:
>
>   a) Developing support materials that can be used in a usual SW
>   Engin.
>      survey course. Such materials might include a description of the
>      activities and deliverables for "lite" process, together with
>      templates and examples of documents and other development
>      products. Students in this course might simply study these, or be
>      asked to do exercises based on these.
>
>   b) Using this "lite" process in a project-oriented course where
>   students
>      work in teams on a semester-long development project. In this
>      course students would be expected to follow the process and
>      create development products according to the process.
>
> QUESTION 1: If you're doing anything like this in a software
> engineering course, or if you're teaching a project course where a
> process is defined and followed, please email me and let me know what
> you're doing. I'm particularly interested in seeing samples or
> templates of things like Quality Assurance Plans, Design documents,
> etc.
>
> QUESTION 2: I would be interested in participating in (or organizing)
> a Birds of a Feather group at SIGCSE 2000 on teaching software process
> or software engineering project courses. If you've already proposed
> something like this, or if you're interested in joining in if I set
> one up, please get in touch.
>
> BTW, I am aware of the process defined as part of CMU's Studio, but
> think we need something simpler for undergraduate courses. I'm also
> aware of Humphrey's work in this area, including the recent TSPi book.
> But again, I think (for now) that this is pretty intense and "large"
> to be incorporated into most undergraduate courses without making a
> major course redesign. I know others will feel different, but that's
> my conclusion after teaching project-centered courses here at FAU and
> at the Univ. of Virginia last spring.
>
> I'll summarize responses back to the list, if there are enough. I am
> also cross-posting this to both the SIGCSE and FASE-Talk email lists,
> so I'll gather replies from each and summarize to both.
>
> Looking forward to hearing from others with similar interests.
> Thanks!
>
> Tom Horton
>
> ----------------------------------------------------------------------
> --- Dr. Thomas B. Horton, Associate Professor Dept. of Computer
> Science and Engineering, Florida Atlantic University Boca Raton, FL
> 33431 USA        Phone: 561/297-2674   FAX: 561/297-2800 Internet:
> tom@cse.fau.edu       WWW: http://www.cse.fau.edu/~tom
>
>
>
>

Subject: Re: teaching software process
Date: Wed, 24 Nov 1999 21:24:28 -0500 (EST)
From: David Alex Lamb <dalamb@cs.queensu.ca>
To: tom@cse.fau.edu
CC: FASE-TALK@ttacs6.ttu.edu

I have been teaching "software process" or "software project" or "overview of
Software Engineering" courses since 1985. For several years I used a non-OO
"lite" process based on my 1988 textbook, "Software Engineering: Planning for
Change", now out of print; the book had simple sample documents in appendices.

This term I've introduced a variant of the process outlined in
Rob Pooley and Perdita Stevens, Using UML: Software Engineering with Objects
and Components, Addison-Wesley, ISBN 0-201-36067-5
for a 3rd year course (http://www.cs.queensu.ca/~dalamb/322/) whose primary
focus is architecture and design documentation, but where the students are
required to prototype their design using a simple Java framework I built
(http://www.cs.queensu.ca/~dalamb/qcis/). The idea of using a framework is to
limit the amount of code they have to write, and to teach them to adapt to a
structure and set of components provided by someone else.

I expect to use this term's best student projects as examples for next year.

The previous incarnation, which did more on configuration management and
quality assurance, and had no framework, was always very challenging for the
students. This year, with the framework, plenty of people build something
reasonable in a few weeks, after 6-8 weeks of design (use cases, conceptual
modeling, interaction diagrams, and selecting a subset of the design to
implement).

Our new Software Design undergraduate program (which begins to deviate from
our current Computer Science program in the 2nd year, starting Fall 2000) will
have a full-year software project course - but it will also have 1-term
courses prior to that on quality assurance, architecture, requirements
analysis, and human-computer interaction.

Subject: ACM's Withdrawal from SWEcc
Date: Sat, 15 Jul 2000 22:01:37 -0500
From: Don Bagert <Don.Bagert@TTU.EDU>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

The current issue of FASE (distributed at about the same time as this
email) mostly concerns ACM's withdrawal from the Software Engineering
Coordinating Committee (SWEcc). I would like to invite and encourage
your comments in FASE-TALK regarding this very important story.

I look forward to some great discussion in this space!

Don Bagert
FASE Professional Issues Editor

--
Donald J. Bagert, Ph.D., P.E.
Professor and Associate Chair
Department of Computer Science
Texas Tech University
8th and Boston
Lubbock TX 79409-3104 USA

Email: Don.Bagert@ttu.edu
Voice: 806-742-1189
Fax: 806-742-3519
URL: http://www.cs.ttu.edu/faculty/bagert.html

Subject: Re: ACM's Withdrawal from SWEcc
Date: Tue, 18 Jul 2000 15:42:15 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
Organization: Mercer University School of Engineering
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

What are the implications of the ACM action for software engineering
accreditation? for CS accreditation?

Don Bagert wrote:

> The current issue of FASE (distributed at about the same time as this
> email) mostly concerns ACM's withdrawal from the Software Engineering
> Coordinating Committee (SWEcc). I would like to invite and encourage
> your comments in FASE-TALK regarding this very important story.
>
> I look forward to some great discussion in this space!
>
> Don Bagert
> FASE Professional Issues Editor
>
> --
> Donald J. Bagert, Ph.D., P.E.
> Professor and Associate Chair
> Department of Computer Science
> Texas Tech University
> 8th and Boston
> Lubbock TX 79409-3104 USA
>
> Email: Don.Bagert@ttu.edu
> Voice: 806-742-1189
> Fax: 806-742-3519
> URL: http://www.cs.ttu.edu/faculty/bagert.html
>
> ---
> You are currently subscribed to fase-talk as: macneil_pe@MERCER.EDU
> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu

Subject: Re: ACM's Withdrawal from SWEcc
Date: Tue, 18 Jul 2000 15:43:12 -0400
From: Chris Starr <starr@CS.cofc.EDU>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Good question. I don't know the motivations that would make ACM do
this. I'll look forward to the conversation. C

>     What are the implications of the ACM action for software engineering
>accreditation? for CS accreditation?
>
>Don Bagert wrote:
>
>> The current issue of FASE (distributed at about the same time as this
>> email) mostly concerns ACM's withdrawal from the Software Engineering
>> Coordinating Committee (SWEcc). I would like to invite and encourage
>> your comments in FASE-TALK regarding this very important story.
>>
>> I look forward to some great discussion in this space!
>>
>> Don Bagert
>> FASE Professional Issues Editor
>>
>> --
>> Donald J. Bagert, Ph.D., P.E.
>> Professor and Associate Chair
>> Department of Computer Science
>> Texas Tech University
>> 8th and Boston
>> Lubbock TX 79409-3104 USA
>>
>> Email: Don.Bagert@ttu.edu
>> Voice: 806-742-1189
>> Fax:   806-742-3519
>> URL:   http://www.cs.ttu.edu/faculty/bagert.html
>>
>> ---
>> You are currently subscribed to fase-talk as: macneil_pe@MERCER.EDU
>> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu
>
>--
>-----------------------------------------------------------------------
>Paul E. MacNeil, Ph.D.
>Associate Professor, Software Engineering Program Director
>School of Engineering
>Mercer University
>1400 Coleman Ave.
>Macon, Georgia 31207
>tel: (912) 301-2185 (effective July 9, 1999, 301 replaced 752)
>fax: (912) 301-2732
>backup fax: (912) 301-2166
>macneil_pe@mercer.edu
>http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
>http://www.accucomm.net/~macneil/index.html
>
>
>
>---
>You are currently subscribed to fase-talk as: starr@CS.COFC.EDU
>To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu

--
-------------------------------------
Christopher W. Starr, Ph.D., Chairman
Department of Computer Science
College of Charleston
66 George Street
Charleston, SC 29424

voice (843) 953-6905
fax (843) 953-8154
mailto:starr@cs.cofc.edu

Subject: RE: ACM's Withdrawal from SWEcc
Date: Tue, 18 Jul 2000 16:13:29 -0500
From: Seletsky Robert Contr SA-ALC/LDAE <rseletsky@onboard-software.com>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

I do not know the imapct for accreditation, but I would hope that the ACM
would work with the IEEE-CS on projects that have no direct relation to
licensing.
From what I have read on the ACM website, it seems that a majority of the
ACM council (and not all ACM members) believes that licensing will not
ensure software reliability especially for safety critical systems.
If the IEEE-CS continues the licensing effort on its own then software
engineering probably will end up in the engineering colleges and will be
heavily influenced by the engineering educational system.
This split between Computer Scientists and the relatively new "Software
Engineers" reminds me of the original split between the Electical Engineers
and the Computer Scientists -- so if history is any guide I feel that
Software Engineering will split off from Computer Science

> -----Original Message-----
> From: Chris Starr [mailto:starr@CS.cofc.EDU]
> Sent: Tuesday, July 18, 2000 2:43 PM
> To: FASE Discussion
> Subject: Re: ACM's Withdrawal from SWEcc
>
>
> Good question. I don't know the motivations that would make ACM do
> this. I'll look forward to the conversation. C
>
> > What are the implications of the ACM action for
> software engineering
> >accreditation? for CS accreditation?
> >
> >Don Bagert wrote:
> >
> >> The current issue of FASE (distributed at about the same
> time as this
> >> email) mostly concerns ACM's withdrawal from the Software
> Engineering
> >> Coordinating Committee (SWEcc). I would like to invite
> and encourage
> >> your comments in FASE-TALK regarding this very important story.
> >>
> >> I look forward to some great discussion in this space!
> >>
> >> Don Bagert
> >> FASE Professional Issues Editor
> >>
> >> --
> >> Donald J. Bagert, Ph.D., P.E.
> >> Professor and Associate Chair
> >> Department of Computer Science
> >> Texas Tech University

> >> 8th and Boston
> >> Lubbock TX 79409-3104 USA
> >>
> >> Email: Don.Bagert@ttu.edu
> >> Voice: 806-742-1189
> >> Fax:   806-742-3519
> >> URL:   http://www.cs.ttu.edu/faculty/bagert.html
> >>
> >> ---
> >> You are currently subscribed to fase-talk as:
> macneil_pe@MERCER.EDU
> >> To unsubscribe send a blank email to
> leave-fase-talk-3002Q@lyris.acs.ttu.edu
> >
> >--
> >-------------------------------------------------------------
> ----------
> >Paul E. MacNeil, Ph.D.
> >Associate Professor, Software Engineering Program Director
> >School of Engineering
> >Mercer University
> >1400 Coleman Ave.
> >Macon, Georgia 31207
> >tel: (912) 301-2185 (effective July 9, 1999, 301 replaced 752)
> >fax: (912) 301-2732
> >backup fax: (912) 301-2166
> >macneil_pe@mercer.edu
> >http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
> >http://www.accucomm.net/~macneil/index.html
> >
> >
> >
> >---
> >You are currently subscribed to fase-talk as: starr@CS.COFC.EDU
> >To unsubscribe send a blank email to
> leave-fase-talk-3002Q@lyris.acs.ttu.edu
>
> --
> -------------------------------------
> Christopher W. Starr, Ph.D., Chairman
> Department of Computer Science
> College of Charleston
> 66 George Street
> Charleston, SC 29424
>
> voice (843) 953-6905
> fax   (843) 953-8154
> mailto:starr@cs.cofc.edu

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 08:59:52 +0100
From: Steve Merrick <Steve.Merrick@marconi.com>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Robert Seletsky wrote:

> This split between Computer Scientists and the relatively
> new "Software Engineers" reminds me of the original split
> between the Electical Engineers and the Computer
> Scientists -- so if history is any guide I feel that
> Software Engineering will split off from Computer Science

Pardon my ignorance, but what's the difference between a Computer Scientist and
a Software Engineer?

Steve Merrick
Software Designer
Marconi Communications

"Who cares, wins"

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 12:32:04 +0300
From: Kari.Hoijarvi@vaisala.com
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

The same as between a physicist and an engineer.

CS curriculums pay very little attention to important SW engineering aspects
like requirements, testing, teamwork, SW project management etc.

Kari

-----Original Message-----
From: Steve Merrick [mailto:Steve.Merrick@marconi.com]
Sent: Wed, 2000-07-19 11:00
To: FASE Discussion
Subject: RE: ACM's Withdrawal from SWEcc

<snip>

Pardon my ignorance, but what's the difference between a Computer Scientist
and a Software Engineer?

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 09:09:39 -0230 (NDT)
From: "Dennis K. Peters" <dpeters@engr.mun.ca>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

> Robert Seletsky wrote:
>
> Pardon my ignorance, but what's the difference between a Computer Scientist and
> a Software Engineer?

It doesn't address exactly your question, but I suggest "Software Engineering
Programmes are not Computer Science Programmes" by David L. Parnas in Anals
of Software Eng., 1998. You can also get this as CRL Report 361 at
http://www.crl.mcmaster.ca/SERG/serg.publications.html or in IEEE Computer,
vol. 16, no. 6 (November/December 1999) pp. 19--30.

Dennis K. Peters, Ph.D., P.Eng.            | dpeters@engr.mun.ca
Faculty of Engineering & Applied Science   | http://www.engr.mun.ca/~dpeters
Memorial University of Newfoundland        | Ph: (709) 737-8929
St. John's, NF Canada A1B 3X5            | Fax: (709) 737-4042

On Wed, 19 Jul 2000, Steve Merrick wrote:

>
>
> Robert Seletsky wrote:
>
> > This split between Computer Scientists and the relatively
> > new "Software Engineers" reminds me of the original split
> > between the Electical Engineers and the Computer
> > Scientists -- so if history is any guide I feel that
> > Software Engineering will split off from Computer Science
>
> Pardon my ignorance, but what's the difference between a Computer Scientist and
> a Software Engineer?
>
> Steve Merrick
> Software Designer
> Marconi Communications
>
> "Who cares, wins"
>
>
>

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 07:51:39 -0500
From: "Anthony J. Duben" <ajduben@semovm.semo.edu>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

At 12:32 PM 7/19/00 +0300, you wrote:
>The same as between a physicist and an engineer.
>
>CS curriculums pay very little attention to important SW engineering aspects
>like requirements, testing, teamwork, SW project management etc.
>

Which is probably a big mistake. Computer science is still a
relatively young field that gets its primary impetus from the
universe of problems that it can be used to solve. The
discipline must maintain an engineering orientation. Otherwise,
it could be come as irrelevant as some of the more arcane
fields of mathematics and theoretical physics.

Even though our degree tracks are in computer science, we
emphasize those very points. It keeps our graduates marketable.

Anthony J. Duben (ajduben@semovm.semo.edu)

>
>Kari
>
>-----Original Message-----
>From: Steve Merrick [mailto:Steve.Merrick@marconi.com]
>Sent: Wed, 2000-07-19 11:00
>To: FASE Discussion
>Subject: RE: ACM's Withdrawal from SWEcc
>
><snip>
>
>Pardon my ignorance, but what's the difference between a Computer Scientist
>and
>a Software Engineer?
>
>---
>You are currently subscribed to fase-talk as: ajduben@semovm.semo.edu
>To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu
>
********************************************************
Anthony J. Duben
Professor and Chairman
Computer Science Dept., MS 5950
Southeast Missouri State University
1 University Plaza
Cape Girardeau MO 63701-4799
phone: 573-651-2194
fax: 573-651-2791
e-mail: ajduben@semovm.semo.edu
or c867buc@semovm.semo.edu

"Education is not the filling of a pail
but the lighting of a fire."
-- William Butler Yeats

"Amateurs talk strategy;
professionals talk logistics."
-- Gen. Oman N. Bradley

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 09:55:31 -0500
From: Norm Gibbs <ngibbs@cs.bsu.edu>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Well, this debate has been much too passive. Let's throw a little kerosene
on the campfire and really get into it. Let's raise some blood pressures.

(The following, however, is not all "tongue-in-cheek" or hyperbole.)

The analogy I like to use is:

A software engineer is to a computer scientist what a mechanical engineer
is to a physicist. Engineers learn in order to build, scientists build in
order to learn. If one characterizes (trivializes) software engineers as
pure designers/programmers then the differences blur. There are different
rewards and value systems. Further, SEs have more of a sense of urgency
about meeting deadlines, consequences of decisions, loyalty to customer and
feeling freer to make tradeoffs (getting a solution that is good enough
rather than the absolute perfect solution).

ACM, due in large part to the honest misconceptions and wrong thinking of
idealist opinion leaders like Bill Wulf and his buddies have deprived the
software development profession of reaping the benefits of having some of
the ablest minds working on some of the most important problems facing
society today -- namely second and third rate software. Think about all
those students who never got an original program to work who are allowed to
put their second and third rate code in products. I shudder to think that I
have probably stepped on airplanes where some piece of code either for air
traffic control, digital fly by wire, on some embedded chip somewhere was
designed/maintained/rewritten/fixed[?] by one of my C- students who never
seemed to get anything to work for my classes and did not understand the
difference between a proof by contradiction and a proof by induction.

Norm

At 08:59 AM 7/19/2000 +0100, you wrote:

>Robert Seletsky wrote:
>
> > This split between Computer Scientists and the relatively
> > new "Software Engineers" reminds me of the original split
> > between the Electical Engineers and the Computer
> > Scientists -- so if history is any guide I feel that
> > Software Engineering will split off from Computer Science
>
>Pardon my ignorance, but what's the difference between a Computer
>Scientist and
>a Software Engineer?
>
>Steve Merrick
>Software Designer
>Marconi Communications
>
>"Who cares, wins"

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 11:16:47 -0400 (EDT)
From: Tim Lethbridge <tcl@site.uottawa.ca>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

I agree with the physics/mechanical engineering analogy (in the message
quoted below), as a description of the way things probably should be and
probably will be in somewhat distant future. The problem is, computer
science programs are currently attempting to educate people for jobs which
are in every sense software engineering -- although this is not being
explicitly recognized by many CS people.

So for now CS and SE programs are targeting students for the same jobs! I
think SE programs should in theory do a better job because they emphasize
what is most important, and de-emphasize aspects of CS that are less
important.

In practice, though, I think that the biggest factors in how students turn
out after graduation have much less to do with differences between CS and
SE curriculum, and more to do with the following factors (starting with
most important):

- Aptitude, IQ, work ethic of students
- Work experience (including co-op)
- Quality of teaching
- Emphasis on problem solving, no matter what problem

So a good CS program could do better than a mediocre CS program at turning
out students.

In an ideal world, universities would cede that the SE curriculum model is
better for most jobs, and direct students to SE programs. CS programs
would be for those students who expect to attend graduate school to
advance the state of the art in narrow fields of computing.

The last paragraph is utopian and hence impossible to achieve because of
the cultural differences, and internecine warfare and misunderstandings
between different groups.

A more practical direction might be to bring CS, SE and general
engineering people together as much as possible, as has been done in our
university, and as was the case with the IEEE/ACM coordinating committee.
The more everybody works together, the more people will come to understand
each other and the better off our students and the industry will be.

So I am completely dismayed by the withdrawal of ACM from the SECC, and am
thinking about withdrawing my membership in protest. But a protest would
only work if it was widely publicized and joined by others.

Tim

On Wed, 19 Jul 2000, Norm Gibbs wrote:

> Well, this debate has been much too passive. Let's throw a little kerosene
> on the campfire and really get into it. Let's raise some blood pressures.
>
> (The following, however, is not all "tongue-in-cheek" or hyperbole.)
>
> The analogy I like to use is:
>
> A software engineer is to a computer scientist what a mechanical engineer
> is to a physicist. Engineers learn in order to build, scientists build in
> order to learn. If one characterizes (trivializes) software engineers as
> pure designers/programmers then the differences blur. There are different
> rewards and value systems. Further, SEs have more of a sense of urgency
> about meeting deadlines, consequences of decisions, loyalty to customer and
> feeling freer to make tradeoffs (getting a solution that is good enough
> rather than the absolute perfect solution).
>
> ACM, due in large part to the honest misconceptions and wrong thinking of
> idealist opinion leaders like Bill Wulf and his buddies have deprived the
> software development profession of reaping the benefits of having some of
> the ablest minds working on some of the most important problems facing
> society today -- namely second and third rate software. Think about all
> those students who never got an original program to work who are allowed to
> put their second and third rate code in products. I shudder to think that I
> have probably stepped on airplanes where some piece of code either for air
> traffic control, digital fly by wire, on some embedded chip somewhere was
> designed/maintained/rewritten/fixed[?] by one of my C- students who never
> seemed to get anything to work for my classes and did not understand the
> difference between a proof by contradiction and a proof by induction.
>
> Norm
>
> At 08:59 AM 7/19/2000 +0100, you wrote:
>
>
> >Robert Seletsky wrote:
> >
> > > This split between Computer Scientists and the relatively
> > > new "Software Engineers" reminds me of the original split
> > > between the Electical Engineers and the Computer
> > > Scientists -- so if history is any guide I feel that
> > > Software Engineering will split off from Computer Science
> >
> >Pardon my ignorance, but what's the difference between a Computer
> >Scientist and
> >a Software Engineer?
> >
> >Steve Merrick
> >Software Designer
> >Marconi Communications
> >
> >"Who cares, wins"
> >
> >
> >
> >---
> >You are currently subscribed to fase-talk as: ngibbs@uconnvm.uconn.edu
> >To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu
>
>
>
> ---
> You are currently subscribed to fase-talk as: tcl@site.uottawa.ca
> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.acs.ttu.edu
>

Timothy C. Lethbridge,                     Assistant Professor
http://www.site.uottawa.ca/~tcl            tcl@site.uottawa.ca
SITE: School of Information Technology and Engineering
University of Ottawa, Canada, K1N 6N5      Office 613 562-5800x6685
Fax: 613 562-5187     Home 613 237-6642    Mobile 613 859-9944

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 16:38:34 +0100
From: Steve Merrick <Steve.Merrick@marconi.com>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Tim Lethbridge wrote:

[snip]
> - Aptitude, IQ, work ethic of students.

<NIT-PICKING>
I would rather see "abstract thinking skills" than "IQ" here. The definition of
IQ is indeterminate, AIUI. It's always easier to go with something whose meaning
is clearer. Is "abstract thinking skills" what you meant, Tim, or am I imposing
my own perspective here? ;-)
</NIT-PICKING>

Now that I understand the difference between SE and CS, I can see why the
distinction is important.

Steve Merrick
Software Designer
Marconi Communications

My employer may or may not agree with the views expressed above.

"Who cares, wins"

Subject: RE: ACM's Withdrawal from SWEcc
Date: Wed, 19 Jul 2000 11:54:01 -0400 (EDT)
From: Tim Lethbridge <tcl@site.uottawa.ca>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

On Wed, 19 Jul 2000, Steve Merrick wrote:
> <NIT-PICKING>
> I would rather see "abstract thinking skills" than "IQ" here. The definition of
> IQ is indeterminate, AIUI. It's always easier to go with something whose meaning
> is clearer. Is "abstract thinking skills" what you meant, Tim, or am I imposing
> my own perspective here? ;-)
> </NIT-PICKING>

Abstract thinking skills would perhaps do. The idea is that I
think the most important factor is whatever students bring to their
university careers in terms of general ability and maturity etc.

We can teach them to think better and improve their abstract thinking to a
considerable extent, but those who already have decent skills (innate or
through prior environment I don't know or care) on entry to university
will end up going a lot further than those who don't.

- Tim

Timothy C. Lethbridge,                     Assistant Professor
http://www.site.uottawa.ca/~tcl            tcl@site.uottawa.ca
SITE: School of Information Technology and Engineering
University of Ottawa, Canada, K1N 6N5      Office 613 562-5800x6685
Fax: 613 562-5187     Home 613 237-6642    Mobile 613 859-9944

Subject: Computer Science vs. Software Engineering
Date: Wed, 19 Jul 2000 09:09:37 -0700
From: Steve Tockey <stevet@construx.com>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

All,
Here are some excerpts from a paper I had in the CSEE&T '99 proceedings
("Recommended Skills & Knowledge for Software Engineers"). It's my stand
on this discussion.

------- Begin Excerpt 1 -------
Science is defined as [3]

     a department of systematized knowledge as an object of study;
     knowledge or a system of knowledge covering general truths or
     the operation of general laws esp. as obtained and tested
     through scientific method

The Accreditation Board of Engineering and Technology (ABET) is the
recognized
authority for accrediting engineering and technology degree programs at
colleges and universities in the United States. ABET defines engineering as
[4]

    … the profession in which a knowledge of the mathematical and
    natural sciences gained by study, experience, and practice is
    applied with judgement to develop ways to utilize, economically,
    the materials and forces of nature for the benefit of mankind

Comparing and contrasting these definitions shows that science is the
pursuit
of knowledge and engineering is the application of that knowledge for the
benefit of people. For example, Chemistry as a science is concerned with
expanding our knowledge of chemical processes in order to better understand
and explain phenomena that can be observed in the universe. Chemical
engineering, on the other hand, applies the knowledge derived from this
"chemical science" to filling human needs. Core to chemical engineering is
an understanding of the body of chemical theory. But, in addition, chemical
engineering calls upon the practical aspects of chemical processes, such as
the design of pressure vessels and waste-heat removal mechanisms, etc.
together with an understanding of (engineering) economy.

Thus, the science branch and the engineering branch of a technical
discipline
are related but distinct. The science branch is concerned with the continued
expansion of the body of theoretical knowledge about that discipline while
the
engineering branch is concerned with the practical and economical
application
of that same theoretical knowledge. The following equation is proposed to be
a
(possibly over-) simplified description of the general relationship between
science and engineering

Engineering = Scientific theory + Practice + (Engineering) Economy

Equation 1

Based on the definition of science, above, computer science can be defined
as

    a department of systematized knowledge about computing as an
    object of study; a system of knowledge covering general truths
    or the operation of general laws of computing esp. as obtained
    and tested through scientific method

Based on the ABET definition of engineering, software engineering can be
defined as

    … the profession in which a knowledge of the mathematical and
    computing sciences gained by study, experience, and practice is
    applied with judgement to develop ways to utilize, economically,
    computing systems for the benefit of mankind

Thus, from Equation 1 we can derive

Software Engineering = Computing theory + Practice + (Engineering)
Economy

Equation 2

Both computer science and software engineering deal with computers,
computing,
and software. The science of computing, as a body of knowledge, is at the
core
of both. Computing science is concerned with computers, computing, and
software
as a system of knowledge, together with the expansion of that knowledge.
Software engineering, on the other hand, should be concerned with the
application of computers, computing, and software to practical purposes,
specifically the design, construction, and operation of efficient and
economical computing systems.
------- End Excerpt 1 -------

------- Begin Excerpt 2 -------
The dictionary defines "economy" as [3]

thrifty and efficient use of resources

Engineering economy is applied microeconomics, where the fundamental
question
is [12]

    Is it in the best interest of the enterprise to invest its limited
    resources in a proposed technical endeavor, or would the same
    investment produce a higher return elsewhere?

>From a business standpoint, profit is not only an organization's goal; it is
necessary for its survival. The ultimate aim of engineering is to create the
most income from the least expense, thus maximizing profit.

>From a government perspective, engineering economy is still very important.
The purpose of the government is to serve its citizens, primarily in terms
of national defense and general welfare. The government is funded through
taxation. Increasing taxation slows the economy, and subtracts from the
general welfare. The aim in government should be to provide the maximum
benefit to the most people while keeping taxation to a minimum. This same
principle applies to any non-profit organization, "How can we satisfy
people's needs in the most cost-effective manner?"

Leon Levy [13] makes some significant observations regarding engineering
economy and its relevance to software engineering

    … software economics has often been misconceived as the means
    of estimating the cost of programming projects. But economics
    is primarily a science of choice, and software economics should
    provide methods and models for analyzing the choices that software
    projects must make.

and

    In any software project there is always a balance between short
    term and long term concerns … economic methods can help us make
    enlightened choices.
------- End Excerpt 2 -------

Finally, a relevant quote from [DeGarmo; Sullivan; and Bontadelli,
Engineering Economy, Ninth Edition, Prentice Hall, 1993]:

Engineering is finding the balance between what is technically
feasible and what is economically acceptable

Thanks for listening,

-- steve

Subject: Re: Computer Science vs. Software Engineering
Date: Wed, 19 Jul 2000 14:49:35 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
Organization: Mercer University School of Engineering
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

I would like to suggest that the right hand sides of equations 1 and 2 be
modified by adding Ethics. So modified, they would read:

ience and engineering

Engineering = Scientific theory + Practice + (Engineering) Economy +
(Engineering) Ethics

Equation 1

Software Engineering = Computing theory + Practice + (Engineering) Economy +
(Engineering) Ethics

Equation 2

Paul

Steve Tockey wrote:

> All,
> Here are some excerpts from a paper I had in the CSEE&T '99 proceedings
> ("Recommended Skills & Knowledge for Software Engineers"). It's my stand
> on this discussion.
> ...
>
>    Engineering = Scientific theory + Practice + (Engineering) Economy
>
>                                Equation 1
>
> ...
>
>     Software Engineering = Computing theory + Practice + (Engineering)
> Economy
>
>                                  Equation 2
>
> ....

--
-----------------------------------------------------------------------
Paul E. MacNeil, Ph.D.
Associate Professor, Software Engineering Program Director
School of Engineering
Mercer University
1400 Coleman Ave.
Macon, Georgia 31207
tel: (912) 301-2185 (effective July 9, 1999, 301 replaced 752)
fax: (912) 301-2732
backup fax: (912) 301-2166
macneil_pe@mercer.edu
http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
http://www.accucomm.net/~macneil/index.html

Subject: Re: Computer Science vs. Software Engineering
Date: Wed, 19 Jul 2000 15:07:39 -0400
From: Mike McCracken <mike@cc.gatech.edu>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

I am enjoying the intellectually motivated discussions, but to me this is
not an issue of someone defining a term or terms to clarify things. Note
that I am commenting on the activities going on external to this list that
prompted Don's original posting, and not the recent discussion.

The real issue is that humans are engaged in emotional and political
arguments that have little to do with the substance of things.

There are a bunch of academics who have never built real software in their
lives deciding the "fate" of software engineering. You know what I mean by
real: operational, maintainable, evolvable, reliable etc. And by the way
that means really operated, maintained, and evolved those systems, not just
talked about it.
(Please don't send me mail telling me you've built real software, cause I
know you have. It's those other guys we need to worry about.)

Given that set, they perceive a couple of things going on. I emphasize
perceive, as this is an emotional/political argument, not intellectual.
The perceptions include, but are not limited to: Those SE folks trying to
dumb down CS by eliminating all of the "<variable name> stuff". Where
variable name can be: hard, good, important, or my. On the other side are
the engineers trying to steal whatever software engineering exists in cs
programs. Because as we all know, engineering is a reserved word. I
recognize that not all universities with cs have engineering programs, and
some cs programs are already in engineering schools.

So what do we have here?
We have a bunch of people who think they know about software engineering,
but who don't, talking about it from an emotional context.
We have an immature field that is trying to define itself, and I think
rightly so.
We have a political process going on between two sanctioning bodies who are
trying to stake out some section of turf, and make claims about the content
of that turf.

What's interesting about all of this, is the real world seems to like
software engineers (thanks for your comments Norm). I have met with
several CEO's of software companies lately and asked them about whether or
not they would hire people with SE undergrad degrees. They almost started
handing me stock options (oh how I wish it were true).

Am I being too cynical here? Sure
Am I negating the true intellectual arguments that need to transpire? Yes
again, but only for effect. The intellectual discussion does need to occur.

I am only stating the obvious. A lot of this is politics/emotions wrapped
in a veil of academic debate.
Might it be more productive if we (all of the people involved in this mess)
really worried about the substantive stuff?

Mike

Subject: Re: Computer Science vs. Software Engineering
Date: Thu, 20 Jul 2000 08:56:01 +0100
From: Steve Merrick <Steve.Merrick@marconi.com>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Mike McCracken wrote:

> The real issue is that humans are engaged in emotional and political
> arguments that have little to do with the substance of things.

I don't disagree with anything Mike said in his posting, excepting the
implication that (as above) the discussion is currently concerned with trivial
or irrelevant matters. Emotional and political matters are of great importance
and significance to us all. To discount the emotional/political side of the
discussion is as blinkered as focussing *only* on the emotional/political side.
Please don't swing from one extreme to the other; stop in the middle. :-)

Just my two pennyworth.

Regards,

Steve Merrick
Software Designer
Marconi Communications

My employer may or may not agree with the opinions I have expressed here.

"Who cares, wins"

Subject: Re: Computer Science vs. Software Engineering
Date: Thu, 20 Jul 2000 07:41:33 -0400
From: Mike McCracken <mike@cc.gatech.edu>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

I was concerned that what I said would be interpreted as Steve said.
I tried to make sure that my comments were directed external to the
discussion occurring on the FASE list. What I was pointing out was, it is
readily apparent that much of the external to this list hubbub is purely
emotional (or a large part of it), and we as the keepers of the flame ought
to stay where we are. Or as Steve said, right in the middle.
Mike

Subject: Software Engineering and Computer Science -- An Operational View
Date: Wed, 26 Jul 2000 17:47:00 -0400 (EDT)
From: SWTQM@aol.com
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
CC: p.willis@ieee.org

I have enjoyed the exchange of opinions concerning SWEs versus CSs, PE
Registration of SWEs, and the ignoring of the qord QUALITY in the SW that is
produced.

I offer an alternative view;:

SWEngrs contribute to the Software Development Lifecycle Phases of
Reguirements, Specifications, Design, Test, while Computer Scientists
literally own the Coding Phase and in many cases can contribute much to the
Design and Test Phases.

Software Engineering is largly a branch of Management, insisting on
auxiliary functions that help improve the quality of the software produced.
Some of these auxiliary functions are:

Requirements Traceability Matrix, Test Traceability Matrix, A well
defined Software Development Process like the CCM of the SEI or a similar
European, British, ASQC, or American Entreperneural offering, Quality
Assurance, Formal Methods, IV and V, Software Reuse, and Configuration
Management.

All of these are SW Engineering functions that employ Computer
Scientist's skills ( often supplied by BSCS graduates ) to improve and prove
the quality of the sw being developed.

The ACM withdrawal from cooperation is a mystery to me. The only mention
I saw was a concern that neither SWEs nor CSs could "prove" that the sw
developed was "error free", and that , somehow, the push to define a PE
registration for SWEngrs was overstating our joint ability to assure
error-free sw.

My view is a bit different. I have a PE in EE but have never had to
invoke it because I haven't ever been as government civilian engineer; still,
colleges like it and it hasn't hurt me. SWEngineering is an Engineering
Discipline tht requires , if done correctly and professionally, knowledge and
skills in simulation of the sw being developed, and appreciation of the
fierce difficulty of Formal Methods, Testing SW, and proving that tha
Requirements are satisfied by the Design and the Code -- things that are
rarely taught in CS departmentseven those connected to Engineering
Departments.

Summing up: SWEngr is a well defined discipline relying on a knowledge
and skill set that is clearly identifiable as "Engineering ".
Computer Science is a curriculum with a wide variance between the
Departments in Engineering Departments and those in Math, Business, or stand
alone. Their leaders have watered down the required amount and span of
analytical skills required to graduate and have placed undo stress on writing
in computer languages rather than teaching them to employ these coding skills
to writing CODE GENERATORS rather than application programs.

SWEngineering is a GRADUATE SUBJECT, not an undergraduate subject. Its
practitioners should have 5 to 10 years experience before they get their MS
in SAEngr. Here is California, we have at least two undergraduate curricula
that one can take and graduate with a BS in SWEngineering. The first classes
haven't graduated yet, but my review of one of the curricula convincved me
that they were producing dilettantes, not professionals.

The astute reader may have noted that I did not mention Metrics among the
SWEngr skills. This is because I know of only one set of Metrics that allows
some prediction of schedule , cost, or time troubles, and consider the field
massively undeveloped. Code metrics may be useful for the next sw project,
but don't help on this project -- if we have the code, we are close to
finished.

Your comments, pro and con, are solicited.

    Paul A. Willis, P.E.
    Software T.Q.M.
    P.O.Box 456
    Altadena, CA 91003
    p.willis@ieee.org

Subject: RE: Software Engineering and Computer Science -- An Operational View
Date: Wed, 26 Jul 2000 21:59:18 -0400
From: Joe Kasser <jkasser@umuc.edu>
Reply-ToFASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

The discussion is interesting, I had to explain the difference to students
and faculty at UMUC and I came up with:

The difference boils down to

Computer Scientists create the components and underlying architectures,
while Software Engineers apply them to make applications.

Regards

Joe Kasser

Subject: Re: Software Engineering and Computer Science -- An Operational View
Date: Thu, 27 Jul 2000 09:28:10 -0500 (CDT)
From: Joe Clifton <clifton@am.uwplatt.edu>
Reply-To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>
To: FASE Discussion <fase-talk@lyris.acs.ttu.edu>

Interesting viewpoints, but I have to take exception
with a couple of notions you put forward.

The notion that CS == "Code & Test" and
it is somehow watered down may be true for
some schools, but I would hope that it is
the minority. Most have gotten well beyond
that several (many?) years ago.

And of course, SE people have to and do code.

I just got back from a trip to San Diego and saw a
great need for some SE's, even those with a "BS".

It doesn't matter if the degree is CS or MIS or SE,
there are programs for which the student comes out
knowing very little and others where they
come out very strong. Even at the MS level!
I've witnessed it WAY too many times.

And of course, as stated earlier in this forum,
even in the same program, there are "A" types
and "C--" types, but both types get "degrees".
And unfortunately, with today's market, both
types get jobs, in some cases working in areas
that just plain scare me!

I have had students that I would put up against anybdy
and others that I was ashamed they got a degree (by
taking and retaking courses for bottom C's in all.)

I get to see both sides, academia and industry, since
I do contract work for a couple of large companies during
the summers.

At my University, we started a BS in SE last year.
I will be the first to admit that it has to have several
changes and we are in the process of making those this summer.
But I consider it to be a rigorous program and so do the
representatives of companies we showed it to (such as
Rockwell, Lucent, Motorola, and several smaller companies).

It boils down to whether we want some SE skills infused
into those developing software. My opinion is, yes and the
more, the better, so long as a solid grounding in CS
(good CS, not the "watered-down programming-language" kind)
is maintained.

It is my opinion that an good SE grad is preferable to
EE+1or2progcourses or a straight CS for most
development jobs.

I think that RIT is an example of a good SE BS program.
And by next year, after we get some changes through
the curriculum process, I expect that I will say
the same for what we have developed!

-Joe Clifton

>    I have enjoyed the exchange of opinions concerning SWEs versus CSs, PE
>Registration of SWEs, and the ignoring of the qord QUALITY in the SW that is
>produced.
>
>    I offer an alternative view;:
>
>    SWEngrs contribute to the Software Development Lifecycle Phases of
>Reguirements, Specifications, Design, Test, while Computer Scientists
>literally own the Coding Phase and in many cases can contribute much to the
>Design and Test Phases.
>
>    Software Engineering is largly a branch of Management, insisting on
>auxiliary functions that help improve the quality of the software produced.
>Some of these auxiliary functions are:
>
>    Requirements Traceability Matrix, Test Traceability Matrix, A well
>defined Software Development Process like the CCM of the SEI or a similar
>European, British, ASQC, or American Entreperneural offering, Quality
>Assurance, Formal Methods, IV and V, Software Reuse, and Configuration
>Management.
>
>    All of these are SW Engineering functions that employ Computer
>Scientist's skills ( often supplied by BSCS graduates ) to improve and prove
>the quality of the sw being developed.
>
>    The ACM withdrawal from cooperation is a mystery to me. The only mention
>I saw was a concern that neither SWEs nor CSs could "prove" that the sw
>developed was "error free", and that , somehow, the push to define a PE
>registration for SWEngrs was overstating our joint ability to assure
>error-free sw.
>
>    My view is a bit different. I have a PE in EE but have never had to
>invoke it because I haven't ever been as government civilian engineer; still,

>colleges like it and it hasn't hurt me. SWEngineering is an Engineering
>Discipline tht requires , if done correctly and professionally, knowledge and
>skills in simulation of the sw being developed, and appreciation of the
>fierce difficulty of Formal Methods, Testing SW, and proving that tha
>Requirements are satisfied by the Design and the Code -- things that are
>rarely taught in CS departmentseven those connected to Engineering
>Departments.
>
>    Summing up: SWEngr is a well defined discipline relying on a knowledge
>and skill set that is clearly identifiable as "Engineering ".
>    Computer Science is a curriculum with a wide variance between the
>Departments in Engineering Departments and those in Math, Business, or stand
>alone. Their leaders have watered down the required amount and span of
>analytical skills required to graduate and have placed undo stress on writing
>in computer languages rather than teaching them to employ these coding skills
>to writing CODE GENERATORS rather than application programs.
>
>    SWEngineering is a GRADUATE SUBJECT, not an undergraduate subject. Its
>practitioners should have 5 to 10 years experience before they get their MS
>in SAEngr. Here is California, we have at least two undergraduate curricula
>that one can take and graduate with a BS in SWEngineering. The first classes
>haven't graduated yet, but my review of one of the curricula convincved me
>that they were producing dilettantes, not professionals.
>
>    The astute reader may have noted that I did not mention Metrics among the
>SWEngr skills. This is because I know of only one set of Metrics that allows
>some prediction of schedule , cost, or time troubles, and consider the field
>massively undeveloped. Code metrics may be useful for the next sw project,
>but don't help on this project -- if we have the code, we are close to
>finished.
>
>    Your comments, pro and con, are solicited.
>
>    Paul A. Willis, P.E.
>    Software T.Q.M.
>    P.O.Box 456
>    Altadena, CA 91003
>    p.willis@ieee.org

Subject: [Fwd: Re: FASE Talk Discussion of ACM/SWEcc]
Date: Mon, 28 Aug 2000 09:33:11 -0500
From: "Dennis J. Frailey" <d-frailey@raytheon.com>
Organization: Raytheon Company

I have been trying unsuccessfully so far to subscribe
to FASE talk. It tells me I am subscribed, then
tells me I cannot send mail because I am not subscribed,
then tells me I cannot subscribe again because I am
already subscribed! Something about my internet hookup
does not seem to please the internet gods.
(Must be CS people instead of SW Engineers!).
(It has to do with the fact that I send mail from
one address and receive it at another due to my
organization's peculiar email setup).

But I think maybe this time it will get through.
If this gets through, here are my comments
on the comments on FASE talk re ACM's
withdrawal from SWEcc.

My basic reaction is that the intellectual and
substantive debate that has occurred on FASE
talk is considerably superior to that which
seems to have occurred in "higher" ACM circles
regarding the subject of software engineering as
a profession. I thank the FASE talk correspondents
for having the discussion that I was unable to
get the ACM "task forces" to engage in.

There is no doubt in my mind that software
engineering is indeed different from
computer science, and I believe (as one of the
people who was around in the 1960's when CS
was being defined)
that CS is more distant
from SW engineering today than it was then.
I attribute this to the "gentrifying"
of CS - the changes that made it
academically respectable in schools
of science, departments of mathematics,
etc.

There is also no doubt in my mind that the
ACM actions were driven more by politics and
emotion and power issues than by substantive
debate. I did learn a lot of political
lessons in the process and I concluded,
among other things, that my computing
colleagues are as emotional, political,
and so forth as any other humans.

It seems such a shame that as a result,
a lot of harm is being done. But I guess
human nature is human nature.

Thanks again to the level headed
individuals who wrote to FASE talk and
renewed my faith in the basic intelligence
and indeed wisdom of a great number of my
colleagues.

Regards, Dennis J. Frailey
(former?) vice-chair of SWEcc
(Although ACM agreed to pull out, nothing
official has happened yet.)

Subject: "Achieving a World-Wide Software Engineering Profession"
Date: Wed, 20 Sep 2000 15:14:32 +0100
From: Helen Edwards <helen.edwards@sunderland.ac.uk>
Organization: University of Sunderland

Call for position papers for a workshop on "Achieving a World-Wide
Software Engineering Profession" to be held at the 14th IEEE Conference
on Software Engineering Education & Training (Theme: In Search of a
Software Engineering Profession), February 19-21 2001, Charlotte, NC,
USA.
Position papers are requested on the following areas:
1. Current situations regarding the licensing/certification of Software
Engineering and IS/IT professionals in different countries (e.g. The
Texas Licensing situation in the USA, Chartered Engineering status in
the UK).
2. What are the likely “drivers” and constraints regarding Software
Engineering Professionalism within particular countries and/or globally.

We would also appreciate papers that address the applicability of IFIP's
proposals regarding harmonisation to the development of a world-wide
software engineering profession (as detailed in the full workshop
proposal that is attached.

Position papers (of one to two side of A4) should be submitted to:
Helen M Edwards (helen.edwards@sunderland.ac.uk) with a copy to
Jeanne Murtagh, (Jeanne.Murtagh@afit.af.mil),

Submissions by: 30th September, 2000
Notification of Acceptance: November 3, 2000
Camera-ready copies due: December 15, 2000

For additional information about conference submission requirements and
conference updates please see: http://www.lrgl.uqam.ca/cseet2001

--
Dr Helen M Edwards, Reader in Software Engineering
School of Computing, Engineering and Technology
University of Sunderland
St Peter's Campus, Sunderland, SR6 0DD, UK
tel: +44 (0)191 515 2786, fax: +44 (0)191 515 2781
e-mail: helen.edwards@sunderland.ac.uk

Subject: SIGCSE Doctoral Consortium
Date: Sat, 11 Nov 2000 10:50:52 -0600
From: "Vicki L. Almstrum" <almstrum@cs.utexas.edu>

We would like to issue a special invitation to students in the
software engineering community to submit an application to the
4th annual SIGCSE Doctoral Consortium. The deadline for
applications is just over a week away (November 19).

The deadline for applications is just a week away. If you are
a qualified student, please consider applying. If you know
students who are qualified to participate, please encourage them
to submit an application.

The SIGCSE Doctoral Consortium is an annual event held in
conjunction with the SIGCSE Technical Symposium each spring.
It is designed primarily for Ph.D. students in computing-related
areas who are planning a career in academia. Students whose
research focus is related to CS education are a primary focus,
although doctoral students in any computing-related area are
welcome to apply.

Since many readers of this list will be attending CSEE&T at the
beginning of that week, it is important to note that the day of
the SIGCSE Doctoral Consortium coincides with the last day
of CSEE&T. I am hopeful that the program committee for CSEE&T
can take this into account so that students wishing to participate
in both events will not be left with too many difficult choices.

Full information about the doctoral consortium can be found at
the following URL:
http://duke.csc.villanova.edu/docConsortium

IMPORTANT DATES:

* The deadline for applications is November 19, 2000.

* Notification of acceptance will be sent by December 15, 2000.

* The Doctoral Consortium will be an all-day event on Wednesday,
February 21, 2001, which is the day before the main events of
the SIGCSE Technical Symposium begin. The Doctoral Consortium
will be held at the conference hotel in Charlotte, NC.

Please contact either of the coordinators if you have questions.

-- John Lewis     <john.lewis@villanova.edu>
   Vicki Almstrum <almstrum@cs.utexas.edu>
-----------------------------------------------------------------------
Vicki L. Almstrum, Ph.D       tel: +1-512-471-9737
Dept of CS, TAY 2.124 (C0500)      +1-512-471-7316 (dept. switchboard)
Univ. of Texas at Austin      fax: +1-512-471-8885
Austin, TX 78712 USA         email: almstrum@cs.utexas.edu
office: TAY 4.118             http://www.cs.utexas.edu/users/almstrum/

Subject: Re: FASE Volume 10 Number 11 November 2000
Date: Fri, 17 Nov 2000 02:23:01 -0500
From: Cem Kaner <kaner@kaner.com>

At 11:24 PM 11/15/00 -0600, the FASE list article:
>From: Don Gotterbarn <gotterba@access.etsu.edu>
>
>ALERT: A danger to the Public and a danger to the development of
> Safe Quality Software in new legislation
>
>Donald Gotterbarn, Software Engineering Ethics Research Institute

I published an extensive discussion of "Software Engineering and UCITA" in the Computer Law
Journal, now posted at http://www.badsoftware.com/engr2000.htm.

-- Cem Kaner
______________________________________________________________________
Cem Kaner, J.D., Ph.D.
Professor, Department of Computer Sciences, Florida Institute of Technology

http://www.kaner.com http://www.badsoftware.com

Author (with Falk & Nguyen) TESTING COMPUTER SOFTWARE (2nd Ed, Wiley)
Author (with David Pels) of BAD SOFTWARE (Wiley, 1998)

This e-mail communication should not be interpreted as legal advice or a legal opinion. The
transmission of this e-mail communication does not create an attorney-client relationship between
me and you. Do not act or rely upon law-related information in this communication without seeking
the advice of an attorney. Finally, nothing in this message should be interpreted as a "digital
signature" or "electronic signature" that can create binding commercial transactions.

Subject: IEEE-CS Certified Software Engineering Professional (CSEP) Program
Date: Mon, 16 Apr 2001 15:50:14 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Organization: Mercer University School of Engineering

The CSEP program( http://www.computer.org/certification/ ) is
undergoing a change that should be of interest, and concern, to software
engineers and software engineering educators. Here are two quotes from
recent email messages (from Stacy Saul at IEEE-CS, the first originally
from Leonard Tripp, Chair, Professional Practices Committee, IEEE
Computer Society):

> I’d
> like to inform you of a change to the program.
>
> The Computer Society has decided to rename the CSEP program, exam, and
> designation. In order to avoid confusion by the public between certificate
> holders and licensed engineers worldwide, the new name will not include the
> words “engineer” or “engineering.”
>
> Rest assured that the exam itself will not change. Though we are changing
> the label, the scope of the exam will remain the same.
>
> In the upcoming weeks, the Professional Practices Committee, which is the
> oversight committee for the Society’s certification efforts, will be
> choosing a new name for the certification program. We will notify you as
> soon as a decision has been made.
>

> I can tell you a couple of names they are considering:
>
> Certified Software Development Professional (CSDP)
> Certified Software Design Professional (CSDP)
> Certified Software Professional (CSP)
>
> Or the same with "IEEE" in front.
>
> Of course, if you have a better idea, feel free to forward it to me!
>
> Thanks,
> Stacy
>
>
>

(Quotations from here on out are my own, except where otherwise
identified - PEM.)

1. I do not think that there is reason for concern about confusion
between licensing and certification. Here is some of my reasoning:

> Lots of engineers from the traditional areas of engineering are not licensed,
> and this does not seem to cause much (if any) confusion for the public.
>
> The CSEP web sites clearly makes the distinction between certification and
> licensing. The word "license" does not appear in the CSEP name or
> description. The web site states
>
> > 1. Certification is not licensure
> >
>
> There are numerous precedents, notably the Microsoft Certified Software
> Engineer (MCSE) and the Novell Certified Engineer (NCE), for certifications
> without licensing. People around the world hold these certificates. Software
> engineering, in this internet age, is global (like so many other things),
> regardless of whether on not any particular government approves.
>
> The American public is already exposed to non-traditional engineering
> disciplines. In March this year, Rational Corp. was cited daily on National
> Public Radio as a supporter, with mention of Rational's work in support of
> "software engineering". Just this week, CNBC, the business cable TV network,
> showed an ad for a job finding service with a grateful client fondling and
> kissing his new business card. His new job title? "Software Engineer." And,
> also just this week, a report on NPR news cited a paper in the "Journal of
> Tissue Engineering" ( http://www.liebertpub.com/TEN/default1.asp ). I am
>
> unaware of any confusion caused by this situation,
> except perhaps with a few engineers from traditional disciplines.
>
> ABET has accepted software engineering as an engineering discipline by creating
> accreditation criteria.
>
> "Genetic engineering" is experiencing a flourishing infancy, and is virtually
> universally referred to as "genetic engineering".
>
> Given this context, how can there be "... confusion by the public ..."
> regarding CSEP and licensing?
>

2. I am concerned about
the Software Engineering Code of Ethics and Professional Practice (Short

Version) Item 6:

> 6. PROFESSION - Software engineers shall advance the integrity and
reputation of the profession consistent
>
> with the public interest.
>

The "integrity and reputation of the profession" would seem to call for
using
the profession's name to name the profession. Our profession already
has a
name, debated for over thirty years, and that name is still "software
engineering". In accepting the designation "Certified Software
Engineering
Professional" we have already taken a step back in using "Professional"
as the
noun, instead of "Engineer". (Most traditional engineers outside civil
engineering are not licensed, but are commonly called "engineers", not
"professionals", anyway.) To now omit "Engineering" even as a adjective
seems
not to advance the profession.

This is all the more so in the context of traditional engineering and
the
MCSE/NCE/etc. certifications. MCSE/NCE are clearly engineering
technology
(rather than engineering) designations, their names not withstanding.
Traditional engineers regard engineering technology programs as less
than
engineering programs, with substantial justification. Now, certified
software
engineers are to be given a title that asserts less than is asserted by
the
(lesser) certifications (MCSE/NCE). This would seem to put software
engineering one step below engineering technology, which is in turn one
step
below engineering. As software engineering struggles for broader
recognition,
it needs to assert itself consistently.

If we are to

> advance the integrity and reputation of the profession consistent with
the public interest
>

then we should we not clearly tell the public the truth, and avoid
circumlocutions? Is this not especially true for the "gold standard" of

certifications?

3. I am also concerned about

> visibility and viability. To avoid the use of the term
> "software engineering" in the name of what is clearly a software engineering
> certificate is in effect a major professional policy statement by the major
> software engineering professional society, IEEE-CS. The software engineering
> community has good people on the Professional Practices Committee, and I am
> sure that they have considered this matter carefully, even if I do not
> understand the rationale for their conclusion. Concerning the "consent of the
> governed", there are a number of other good people in software engineering who
> are active in the advancement of the profession.
>
...

> Some of them can be found at CSEE&T. Without their sincere respect and
> support, the certificate is (and should be) doomed. Their respect and support
> will come only if they understand and support the decision process and result.
>

In response to a query, Don Bagert informed me that

> The issue is simple: Texas
> Board of Professional Engineers have objected to the use of the terms "engineer" or
"engineering professional"
> in the title, and the Texas Board has state law backing it up. NCEES, acting on behalf of
the engineering state
> licensing boards, has also expressed concern. I think there should be as wide a discussion
as possible -
>
....

The people on the Professional Practices Committee are good and
honorable people all, and they have made and continue to make
substantial contributions to software engineering. They are not the
problem.

What are the options, and what are the consequences? How are the
MCSE and NCE dealt with in Texas? What would happen if IEEE-CS went
ahead with the CSEP designation as originally formulated?

Don Bagert's recent exchange with the professional engineers
organization (included in the April 2001 issue of the FASE newsletter)
shows how far we have to go in establishing our profession to the
outside world. Software engineering makes use of different engineering
science and mathematics from those used by traditional engineering
areas. It is doubtless a shock, and a challenge, for traditional
engineering to be confronted with so much change of such great diversity
(e.g. software engineering, genetic engineering, and tissue
engineering). It was (and is) a great shock and challenge to applied
computing to see the established 1960's approaches for software
development and maintenance swept away by newer, better approaches
(i.e., software engineering). These changes are driven by forces
outside the control of organizations, and will happen regardless of
them. The real issue is how to proceed in fostering these changes.

What do you think?

Paul

--
-----------------------------------------------------------------------
Paul E. MacNeil, Ph.D.
Associate Professor, Software Engineering Program Director
School of Engineering
Mercer University
1400 Coleman Ave (for standard deliveries)
1200 Prince St. (for overnight and FedEx deliveries)
Macon, Georgia 31207
tel: (478) 301-2185 [note new area code]
fax: (478) 301-2732
macneil_pe@mercer.edu
http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
http://www.accucomm.net/~macneil/index.html

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 16 Apr 2001 17:55:34 -0400 (EDT)
From: Tim Lethbridge <tcl@site.uottawa.ca>

Dear FASE-talkers,

Here is a copy of a letter I sent to Leonard Tripp regarding the potential
change of name of the CSEP. I have not received a response, but I think
that if other members of FASE-talk are concerned they should write to him
too. I think the IEEE should keep 'software engineering' in the name of
their certification program no matter what the Texas Board thinks. An
international organization like the IEEE should not allow itself to be
bullied by the Texas Board.

For those who are not aware of this program, see
http://www.computer.org/certification/

- Tim

---------- Forwarded message ----------
Date: Wed, 11 Apr 2001 17:09:05 -0400 (EDT)
From: Tim Lethbridge <tcl@site.uottawa.ca>
To: l.tripp@computer.org
Cc: SSaul@computer.org, certification@computer.org, Don.Bagert@ttu.edu,
s.seidman@computer.org, s.mcconnell@computer.org, pvoldner@sympatico.ca,
j.carlo@computer.org, d-frailey@raytheon.com, amkelly@computer.org
Subject: Re: CSEP Program - Information regarding program change

Dear Leonard,

I am participating as a CSEP beta tester out of the spirit of
participation and personal interest, not to obtain credentials. So I will
continue to participate at least until I hear what the chosen name will
be.

However I think that changing the name so that it does not include the
term 'software engineering' is a very grave error -- It will wipe out much
of the value of the certification and probably doom it to obscurity.

I can think of no name lacking 'software engineering' which would capture
the intent correctly. After all, the study materials all cover the field
that the IEEE and others have identified as 'software engineering'. You
can't call it 'development', or anything similar, because they have
different meanings. The closest I could imagine is 'Certified Software
Professional', but that is not specific enough.

The IEEE Computer Society would actually be doing the public a favour by
creating a 'real' exam and certification process in software enginering
(in contrast, for example, to the MCSE). Judging by the sample questions
and other criteria, you have done a very good job. The public will be able
to look at a person with this certification and trust that they have an
appropriate level of knowledge in *software enginering*.

Students who have a degree in Software Engineering are not necessarily
registered with engineering societies either, but nobody would be
confused by someone saying they have a 'Bachelor of Engineering in
Software Engineering'. Why should the CSEP be any different (your
requirements are largely a superset of a BEng(SE).

I think the IEEE Computer Society should lead the way on this and stick
with 'software engineering'. Somebody has to lead the way internationally.
It might be, in fact, that some state/provincial/national engineering
bodies might come to use the CSEP as one of the bases for their licensing
process.

If you do have to make a change, how about 'IEEE Certified Software
Engineering Professional (ICSEP)'? Just keep the 'software engineering'.
Anything else really *would* cause confusion.

Sincerely
Dr. Timothy C. Lethbridge
Senior member, IEEE
Program chair, Conference on Software Engineering Education and Training

--
Timothy C. Lethbridge,                     Associate Professor
http://www.site.uottawa.ca/~tcl            tcl@site.uottawa.ca
SITE: School of Information Technology and Engineering
University of Ottawa, Canada, K1N 6N5      Office: 613 562-5800x6685
Fax: 613 562-5187    Home: 613 237-6642    Mobile: 613 859-9944
Co-author of McGraw Hill textbook -- Object Oriented Software Engineering:
Practical Software Development using UML and Java. See www.lloseng.com

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 16 Apr 2001 17:31:14 -0500
From: "Dennis J. Frailey" <d-frailey@raytheon.com>
Organization: Raytheon Company

Just a point of fact.
The Texas board has legal obligations in this matter.
I am working with them to try to mitigate
this but a confrontation will not help matters.
Lawyers do run the world.

DJF

Just a point of fact.
The Texas board has legal obligations in this matter.
I am working with them to try to mitigate
this but a confrontation will not help matters.
Lawyers do run the world.

DJF

Tim Lethbridge wrote:
>
> Dear FASE-talkers,
>
> Here is a copy of a letter I sent to Leonard Tripp regarding the potential
> change of name of the CSEP. I have not received a response, but I think
> that if other members of FASE-talk are concerned they should write to him
> too. I think the IEEE should keep 'software engineering' in the name of
> their certification program no matter what the Texas Board thinks. An
> international organization like the IEEE should not allow itself to be
> bullied by the Texas Board.
>
> For those who are not aware of this program, see
> http://www.computer.org/certification/
>
> - Tim
>
> ---------- Forwarded message ----------
> Date: Wed, 11 Apr 2001 17:09:05 -0400 (EDT)
> From: Tim Lethbridge <tcl@site.uottawa.ca>
> To: l.tripp@computer.org
> Cc: SSaul@computer.org, certification@computer.org, Don.Bagert@ttu.edu,
>     s.seidman@computer.org, s.mcconnell@computer.org, pvoldner@sympatico.ca,
>     j.carlo@computer.org, d-frailey@raytheon.com, amkelly@computer.org
> Subject: Re: CSEP Program - Information regarding program change
>
> Dear Leonard,
>
> I am participating as a CSEP beta tester out of the spirit of
> participation and personal interest, not to obtain credentials. So I will
> continue to participate at least until I hear what the chosen name will
> be.
>
> However I think that changing the name so that it does not include the
> term 'software engineering' is a very grave error -- It will wipe out much
> of the value of the certification and probably doom it to obscurity.
>
> I can think of no name lacking 'software engineering' which would capture
> the intent correctly. After all, the study materials all cover the field
> that the IEEE and others have identified as 'software engineering'. You
> can't call it 'development', or anything similar, because they have
> different meanings. The closest I could imagine is 'Certified Software
> Professional', but that is not specific enough.
>
> The IEEE Computer Society would actually be doing the public a favour by
> creating a 'real' exam and certification process in software enginering
> (in contrast, for example, to the MCSE). Judging by the sample questions
> and other criteria, you have done a very good job. The public will be able
> to look at a person with this certification and trust that they have an
> appropriate level of knowledge in *software enginering*.
>
> Students who have a degree in Software Engineering are not necessarily
> registered with engineering societies either, but nobody would be
> confused by someone saying they have a 'Bachelor of Engineering in
> Software Engineering'. Why should the CSEP be any different (your
> requirements are largely a superset of a BEng(SE).
>
> I think the IEEE Computer Society should lead the way on this and stick
> with 'software engineering'. Somebody has to lead the way internationally.
> It might be, in fact, that some state/provincial/national engineering
> bodies might come to use the CSEP as one of the bases for their licensing
> process.
>
> If you do have to make a change, how about 'IEEE Certified Software
> Engineering Professional (ICSEP)'? Just keep the 'software engineering'.
> Anything else really *would* cause confusion.
>
> Sincerely
> Dr. Timothy C. Lethbridge
> Senior member, IEEE
> Program chair, Conference on Software Engineering Education and Training
>
> --
> Timothy C. Lethbridge,                     Associate Professor
> http://www.site.uottawa.ca/~tcl            tcl@site.uottawa.ca
> SITE: School of Information Technology and Engineering
> University of Ottawa, Canada, K1N 6N5      Office: 613 562-5800x6685
> Fax: 613 562-5187    Home: 613 237-6642    Mobile: 613 859-9944
> Co-author of McGraw Hill textbook -- Object Oriented Software Engineering:
> Practical Software Development using UML and Java. See www.lloseng.com
>

--
Dennis J. Frailey                D-Frailey@Raytheon.com (email)
Principal Fellow                 972-575-0800 (voice)
Raytheon Company                 972-575-6442 (fax)
6620 Chase Oaks Blvd             972-558-8613 (pager)
MS 8528    PSK9
Plano, TX 75023

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 17 Apr 2001 09:37:53 -0230 (NDT)
From: "Dennis K. Peters" <dpeters@engr.mun.ca>

Tim et al,

I think that the problem with CSEP is not the S but the P -- in most, if
not all, Canadian provinces (and I expect this is the case in Texas) the
use of "Engineer" and "Professional" together is restricted under the
provincial engineering laws. In Newfoundland, the "Engineering and
Geoscientists Act" (5.2) says:

No person, corporation, partnership or other association of persons,
except a professional engineer, licensee or permit holder, shall
    (a) use the word "engineer" or "engineering" in combination with a
    name, title, description, letter, symbol or abbreviation, except a
    registered engineering geologist, that represents expressly or by
    implication that he or she is a professional engineer, licensee or
    permit holder,
    ...

IMHO, to present yourself as a "Certified Software Engineering
Professional" is pretty clearly a violation of that law. While APEGN (the
provincial association charged with enforcing the act) isn't big enough
to push IEEE around (any more than they could push Micro$oft around),
they do have the strength of law behind them here, and are quite capable
of going after individuals.

Clearly the IEEE can't be expected to bend to the whims of the legislative
bodies in every jurisdiction in which they have members -- the members
themselves have to be responsible for their own actions. However, I think
it is prudent of IEEE to consider very carefully the value of issuing
certificates with titles that, in a substantial number of jurisdictions,
can't be legally used.

Dennis

On Mon, 16 Apr 2001, Tim Lethbridge wrote:

> Dear FASE-talkers,
>
> Here is a copy of a letter I sent to Leonard Tripp regarding the potential
> change of name of the CSEP. I have not received a response, but I think
> that if other members of FASE-talk are concerned they should write to him
> too. I think the IEEE should keep 'software engineering' in the name of
> their certification program no matter what the Texas Board thinks. An
> international organization like the IEEE should not allow itself to be
> bullied by the Texas Board.
>
> For those who are not aware of this program, see
> http://www.computer.org/certification/
>
> - Tim
>
> ---------- Forwarded message ----------
> Date: Wed, 11 Apr 2001 17:09:05 -0400 (EDT)
> From: Tim Lethbridge <tcl@site.uottawa.ca>
> To: l.tripp@computer.org
> Cc: SSaul@computer.org, certification@computer.org, Don.Bagert@ttu.edu,
>     s.seidman@computer.org, s.mcconnell@computer.org, pvoldner@sympatico.ca,
>     j.carlo@computer.org, d-frailey@raytheon.com, amkelly@computer.org
> Subject: Re: CSEP Program - Information regarding program change
>
> Dear Leonard,
>
> I am participating as a CSEP beta tester out of the spirit of
> participation and personal interest, not to obtain credentials. So I will
> continue to participate at least until I hear what the chosen name will
> be.
>
> However I think that changing the name so that it does not include the
> term 'software engineering' is a very grave error -- It will wipe out much
> of the value of the certification and probably doom it to obscurity.
>
> I can think of no name lacking 'software engineering' which would capture
> the intent correctly. After all, the study materials all cover the field
> that the IEEE and others have identified as 'software engineering'. You
> can't call it 'development', or anything similar, because they have
> different meanings. The closest I could imagine is 'Certified Software
> Professional', but that is not specific enough.
>
> The IEEE Computer Society would actually be doing the public a favour by
> creating a 'real' exam and certification process in software enginering
> (in contrast, for example, to the MCSE). Judging by the sample questions
> and other criteria, you have done a very good job. The public will be able
> to look at a person with this certification and trust that they have an
> appropriate level of knowledge in *software enginering*.
>
> Students who have a degree in Software Engineering are not necessarily
> registered with engineering societies either, but nobody would be
> confused by someone saying they have a 'Bachelor of Engineering in
> Software Engineering'. Why should the CSEP be any different (your
> requirements are largely a superset of a BEng(SE).
>
> I think the IEEE Computer Society should lead the way on this and stick
> with 'software engineering'. Somebody has to lead the way internationally.
> It might be, in fact, that some state/provincial/national engineering
> bodies might come to use the CSEP as one of the bases for their licensing
> process.
>
> If you do have to make a change, how about 'IEEE Certified Software
> Engineering Professional (ICSEP)'? Just keep the 'software engineering'.
> Anything else really *would* cause confusion.
>
> Sincerely
> Dr. Timothy C. Lethbridge
> Senior member, IEEE
> Program chair, Conference on Software Engineering Education and Training
>
> --
> Timothy C. Lethbridge,                     Associate Professor
> http://www.site.uottawa.ca/~tcl            tcl@site.uottawa.ca
> SITE: School of Information Technology and Engineering
> University of Ottawa, Canada, K1N 6N5      Office: 613 562-5800x6685
> Fax: 613 562-5187    Home: 613 237-6642    Mobile: 613 859-9944
> Co-author of McGraw Hill textbook -- Object Oriented Software Engineering:
> Practical Software Development using UML and Java. See www.lloseng.com

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 17 Apr 2001 12:12:34 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Organization: Mercer University School of Engineering

Conflicting requirements. We must use "software engineering", to support our
profession, and we are forbidden to use "software engineering", to avoid legal
troubles to various parties.

How many good systems have been built on conflicting requirements?

On the other hand, Dennis and others may suceed in finessing this matter well
enough for it to work out. Let's hope. I do agree with Dennis' comment to the
effect thta frontal assault is not an appropriate tactic now.

Paul

"Dennis K. Peters" wrote:

> Clearly the IEEE can't be expected to bend to the whims of the legislative
> bodies in every jurisdiction in which they have members -- the members
> themselves have to be responsible for their own actions. However, I think
> it is prudent of IEEE to consider very carefully the value of issuing
> certificates with titles that, in a substantial number of jurisdictions,
> can't be legally used.
>
> Dennis
>
> Dennis K. Peters, Ph.D., P.Eng.            | dpeters@engr.mun.ca
> Faculty of Engineering & Applied Science   | http://www.engr.mun.ca/~dpeters
> Memorial University of Newfoundland        | Ph: (709) 737-8929
> St. John's, NF Canada A1B 3X5            | Fax: (709) 737-4042

--
-----------------------------------------------------------------------
Paul E. MacNeil, Ph.D.
Associate Professor, Software Engineering Program Director
School of Engineering
Mercer University
1400 Coleman Ave (for standard deliveries)
1200 Prince St. (for overnight and FedEx deliveries)
Macon, Georgia 31207
tel: (478) 301-2185 [note new area code]
fax: (478) 301-2732
macneil_pe@mercer.edu
http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
http://www.accucomm.net/~macneil/index.html

Subject: RE: CSEP Program - Information regarding program change (fwd)
Date: Tue, 17 Apr 2001 11:12:55 -0500
From: Seletsky Robert Contr SA-ALC/LDAE <rseletsky@KELLY.AF.MIL>

Dr MacNeil and group,

    I agree that it is a person's responsibility to ensure that they are
using their awarded titles legally in their jurisdiction.
    If someone does not agree with the current law then they should
constructively work for the law to be changed.
    I would like to point out that it is also probably illegal for a Texas
resident (and residents of many other jurisdictions) to state they are an
IEEE member on their business card.
    Perhaps this legal title protection issue will start a discussion within
the IEEE of changing its name.
    Ultimately this is a political/legal issue, which makes it so
interesting.

Sincerely,

Robert Seletsky
Software Developer
OnBoard Software, Inc.
404 Greig Street, Bldg. 178
Kelly AFB TX 78241
Voice: (210) 925-3065
Fax: (210) 925-2144
rseletsky@onboard-software.com

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 15 May 2001 11:16:09 -0500
From: "Hensley, David W" <david.hensley@compaq.com>

I also sent a message to Leonard (no response to date). I just received my
PE license and I'd like to be able to use a title from the IEEE
certification that has "engineer" in it someplace. I'm proud of being a
software engineer and I'd like the title to go with it. The gist of my
letter was a suggestion to look at the medical specialties as a model. The
doctors don't use terms like "Certified Internal Medicine Professional",
they use terms like "Diplomate of the Institute of Whatever". The
implication is that their being certified and professional is so obvious
that it need not be said. IMHO words like "certified" and "professional"
have been tainted by the vendor certification titles and should not be
used. I'd like there to be some difference between my title and the
16-year old with an MCP...

I'm not a lawyer, but would a term such as "Diplomate of the Institute of
Software Engineering" or "Fellow of the Institute of Software Engineering"
avoid the problem? These types of titles are at least differentiable from
the Microsoft/Novell/Cisco titles, and again IMHO, sound much more
professional. Of course, there is the problem of creating a "Institute of
Software Engineering" ... ;)

Regardless of the outcome, it's exciting to be involved in the creation of
a new engineering discipline.

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Sun, 20 May 2001 20:44:53 -0400
From: Jim Vallino <jrv@cs.rit.edu>

At 12:16 PM 5/15/2001, Hensley, David W wrote:
> The
>doctors don't use terms like "Certified Internal Medicine Professional",
>they use terms like "Diplomate of the Institute of Whatever".

This is not a true statement. The standard terminology is that a physician
is "board certified" in their specialty. Many of the ads in the yellow
pages will state this. My wife is a physician. The studying she just did
was for her board "recertification". I here the term all the time.

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 21 May 2001 07:41:49 -0700
From: "Hensley, David W" <david.hensley@compaq.com>

Jim Vallino wrote:
>This is not a true statement. The standard terminology is that a physician

>is "board certified" in their specialty. Many of the ads in the yellow
>pages will state this. My wife is a physician. The studying she just did
>was for her board "recertification". I here the term all the time.

Jim,

Thanks for the info. The one I'm most familiar with is the American Board of
Family Practice. They are indeed a board, and they do certify, but they seem
pretty consistent in referring to those with certificates as "diplomates". I
did grab the yellow pages and saw what you were saying--there was even some
boilerplate about listing in a specialty was de facto evidence of board
certification. It looks to me like the generic process and term is "board
certification", but that a lot of the boards have wrapped some other
terminology around the standard terms.

I guess I was hoping that, even though we are introducing a certification,
we could dress it up a little to distinguish it from the flood of other
certificates out there that don't, to put it nicely, require the breadth of
knowledge and experience that the CSEP will require. I obtained an MCP for
NT 4.0 without ever having logged into an NT system, for example. It took
about 3 weeks. If I had spent 3 more weeks and another $300, I could have
been a M$ Certified Systems Engineer. Sure cheapens the 2-1/2 years and $$$
I spent getting the Masters in Systems Engineering.

Haven't seen many physicians with the word "professional" in their titles,
though. :)

Again, it appears as though we are in the middle of creating a certification
board for software engineers. Can we structure the title used for those
holding certificates to something like "Diplomate of" <boardname> where
<boardname> contains the phrase "Software Engineering", without running
afoul of the state engineering boards? If so, I believe that an acronym such
as D.B.S.E. (Diplomate of the Board of Software Engineering) or something
similar would help the general public differentiate CSEP holders from the
flood of MCPs, MCSEs, CNEs, CIPs, etc., etc...

And now, back to studying...

Dave

-----Original Message-----
From: Jim Vallino [mailto:jrv@cs.rit.edu]
Sent: Sunday, May 20, 2001 19:45
To: FASE Discussion
Cc: FASE Discussion

Subject: Re: CSEP Program - Information regarding program change (fwd)

At 12:16 PM 5/15/2001, Hensley, David W wrote:
> The
>doctors don't use terms like "Certified Internal Medicine Professional",
>they use terms like "Diplomate of the Institute of Whatever".

--
Jim Vallino                           Rochester Institute of Technology
jrv@cs.rit.edu                        Departments of Computer Science
http://www.cs.rit.edu/~jrv                   and Software Engineering
(716)475-2991 Fax: (716)475-7100     102 Lomb Memorial Drive
                                       Rochester, NY 14623-5608

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 21 May 2001 11:27:00 -0400
From: David Klappholz <d.klappholz@worldnet.att.net>

>At 12:16 PM 5/15/2001, Hensley, David W wrote:
>> The
>>doctors don't use terms like "Certified Internal Medicine Professional",
>>they use terms like "Diplomate of the Institute of Whatever".
>
This is not a true statement.

I'm afraid it is true.

Someone has already addressed the term "diplomate," which I wasn't
aware was used by any American medical certification boards, but
apparently is. Another term that is used is "Fellow of," with no
more meaning than "board certified by" as in FACS = Fellow of the
American College of Surgeons. A board certified surgeon announces
that fact by simply putting the initial FACS after his/her name.

Dave

>   The standard terminology is that a physician is "board certified"
>in their specialty. Many of the ads in the yellow pages will state
>this. My wife is a physician. The studying she just did was for
>her board "recertification". I here the term all the time.
>
>--
>Jim Vallino                           Rochester Institute of Technology
>jrv@cs.rit.edu                        Departments of Computer Science
>http://www.cs.rit.edu/~jrv                   and Software Engineering
>(716)475-2991 Fax: (716)475-7100     102 Lomb Memorial Drive
>                                       Rochester, NY 14623-5608
>
>
>---
>You are currently subscribed to fase-talk as: d.klappholz@worldnet.att.net
>To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.ttu.edu

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 21 May 2001 14:05:58 -0500
From: "Dennis J. Frailey" <d-frailey@raytheon.com>
Organization: Raytheon Company

This discussion illustrates why this subject is so confusing.
"Certified" or "licensed" or "registered" is an ADJECTIVE,
and not usually part of a title.

Consider physicians.
The title adopted by a physician who is "board certified"
is something like "Fellow of the American College of Surgeons",
or "Diplomate of the International Board of Obstetricians"
(the latter was made up to illustrate the concept).
The physician would typically use letters after their name
to indicate this status, such as
Dr. John Doe, FACS or Dr. Mary Smith, DIBO.
This would be used in professional contexts, not in
social ones.

The title on the physician's certificate from the board of
whatever is typically spelled out in full, as in
Fellow of the board of ... or Diplomate of the society of ...
(check your doctor's wall the next time you see him or her).

But both of the above are ways of stating that the physician
is "board certified", even though the term "certified" does
not appear in the title - rather, the title appears ON the
certificate. The physician is said to be "certified" because
he or she has received a certificate!

An analogy occurs with registered or licensed professional engineers.
Their title does not say "registered" or "licensed". It says
"professional engineer" and they use the title "John Doe, PE".

To extend this to software, if someone were a "certified
software engineer" their title might be something like
"Fellow of the International Society of Software Engineers".

One exception I know of is accountants, where CPA stands for
"certified public accountant". Of course in this case "certified"
really means "licensed". I just thought I would throw that in
to show how confusing the subject can get :-)

The real point is that whatever the title, it ought to stand
for something if it is expected to have any significance.

Regards, Dennis Frailey

David Klappholz wrote:
>
> >At 12:16 PM 5/15/2001, Hensley, David W wrote:
> >> The
> >>doctors don't use terms like "Certified Internal Medicine Professional",
> >>they use terms like "Diplomate of the Institute of Whatever".
> >
> This is not a true statement.
>
> I'm afraid it is true.
>
> Someone has already addressed the term "diplomate," which I wasn't
> aware was used by any American medical certification boards, but
> apparently is. Another term that is used is "Fellow of," with no
> more meaning than "board certified by" as in FACS = Fellow of the
> American College of Surgeons. A board certified surgeon announces
> that fact by simply putting the initial FACS after his/her name.
>
> Dave
>
> >   The standard terminology is that a physician is "board certified"
> >in their specialty. Many of the ads in the yellow pages will state
> >this. My wife is a physician. The studying she just did was for
> >her board "recertification". I here the term all the time.
> >
> >--
> >Jim Vallino                           Rochester Institute of Technology
> >jrv@cs.rit.edu                        Departments of Computer Science
> >http://www.cs.rit.edu/~jrv                   and Software Engineering
> >(716)475-2991 Fax: (716)475-7100     102 Lomb Memorial Drive
> >                                       Rochester, NY 14623-5608
> >
> >
> >---
> >You are currently subscribed to fase-talk as: d.klappholz@worldnet.att.net
> >To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.ttu.edu
>
> ---
> You are currently subscribed to fase-talk as: d-frailey@raytheon.com
> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.ttu.edu

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Mon, 21 May 2001 15:56:11 -0400
From: Mike McCracken <mike@cc.gatech.edu>

This has probably already been said, but I didn't see it. Remember
physicians have a license to practice medicine (that's what they get when
they pass their board exams). After that, and years of indenture and
training they become so-called "real physicians" and then go onto board
certification in areas of specialization. Note also, you don't need to be
board certified to specialize. I could call myself a surgeon and not be
board certified, just an MD. That's why its always a good idea to check if
the specialist is board certified.
Mike

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 22 May 2001 06:39:16 -0700
From: "Hensley, David W" <david.hensley@compaq.com>

Dennis J. Frailey wrote
>
> To extend this to software, if someone were a "certified
> software engineer" their title might be something like
> "Fellow of the International Society of Software Engineers".
>
>

So any speculation on the reaction of state engineering boards to displaying
a title of "Fellow of the International Society of Software Engineers" to
the public? Sure sounds good--mom would be proud ;)

Cheers,

Dave

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 22 May 2001 10:05:53 -0500
From: Robert Seletsky <rseletsky@onboard-software.com>

I beieve every state has its own engineering licensure laws, but here is
part of the Texas Engineering Practice Act from the website
http://www.tpbe.state.tx.us

Section 1. This Act shall be known and may be cited as "The Texas
Engineering Practice Act."

Section 1.1. In recognition of the vital impact which the rapid advance of
knowledge of the mathematical, physical and engineering sciences as applied
in the practice of engineering is
having upon the lives, property, economy and security of our people and the
national defense, it is the intent of the Legislature, in order to protect
the public health, safety and welfare,
that the privilege of practicing engineering be entrusted only to those
persons duly licensed and practicing under the provisions of this Act and
that there be strict compliance with and
enforcement of all the provisions of this Act, and, in order that the state
and members of the public may be able to identify those duly authorized to
practice engineering in this state and
fix responsibility for work done or services or acts performed in the
practice of engineering, only licensed persons shall practice, offer or
attempt to practice engineering or call themselves
or be otherwise designated as any kind of an "engineer" or in any manner
make use of the term "engineer" as a professional, business or commercial
identification, title, name,
representation, claim or asset, and all the provisions of this Act shall be
liberally construed and applied to carry out such legislative intent. In
furtherance of such intent and purpose of
the Legislature, the practice of engineering is hereby declared a learned
profession to be practiced and regulated as such, and its practitioners in
this state shall be held accountable to
the state and members of the public by high professional standards in
keeping with the ethics and practices of the other learned professions in
this state. There is specifically reserved to
graduates of all public universities recognized by the American Association
of Colleges and Universities the right to disclose any college degrees
received by such individual and use
the word Graduate Engineer on his stationery, business cards, and personal
communications of any character.

Section 1.2. PROHIBITED ACTS AND CONDUCT. (a) From and after the effective
date of this Act, unless duly licensed in accordance with the provisions of
this Act, no person in this
state shall:

(1) Practice, continue to practice, offer or attempt to practice engineering
or any branch or part thereof.

(2) Directly or indirectly, employ, use, cause to be used or make use of any
of the following terms or any combinations, variations or abbreviations
thereof as a professional, business or
commercial identification, title, name, representation, claim, asset or
means of advantage or benefit: "engineer," "professional engineer,"
"licensed engineer," "registered engineer,"
"registered professional engineer," "licensed professional engineer,"
"engineered."

(3) Directly or indirectly, employ, use, cause to be used or make use of any
letter, abbreviation, word, symbol, slogan, sign or any combinations or
variations thereof, which in any manner
whatsoever tends or is likely to create any impression with the public or
any member thereof that any person is qualified or authorized to practice
engineering unless such person is duly
licensed under and practicing in accordance with the provisions of this Act.

(4) Receive any fee or compensation or the promise of any fee or
compensation for performing, offering or attempting to perform any service,
work, act or thing which is any part of the
practice of engineering as defined by this Act.

(b) Within the intent and meaning and for all purposes of this Act, any
person, sole proprietorship, firm, partnership, association or corporation
which shall do, offer or attempt to do any
one or more of the acts or things set forth in Subsection (a) of this
section shall be conclusively presumed and regarded as engaged in the
practice of engineering.

Section 1.3. Every person licensed by the Board to engage in the practice of
engineering shall in the professional use of his name on any sign,
directory, listing, contract, document,
pamphlet, stationery, letterhead, advertisement, signature, or any other
such means of professional identification, written or printed, use one of
the following legally required
identifications: Engineer, Professional Engineer or P.E.

It seems to me that, at least in Texas, the use of any title by an
unlicensed person containing "engineer" would be illegal.
Do other countries treat the "engineer" title in a similar manner?

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 22 May 2001 10:38:40 -0500
From: Dennis J Frailey <d-frailey@raytheon.com>

The various US states (and other jurisdictions such as DC and
Puerto Rico) vary in their laws, but all are based on a common "model" law
developed by the NCEES, the group that develops and conducts PE
examinations within the US.
Canada has a similar system and similar laws.
Texas law conforms fairly closely to the model law,
differing mainly in that the Texas Legislature has extended their laws
to support NAFTA by recognizing engineers licensed in Canada and Mexico
(for various reasons, other jurisdictions have been slower to respond to
NAFTA).

Note: boards of engineers communicate the laws, enforce the laws, and
administer the process of licensing. Only legislatures or other government
bodies establish laws. This is often misunderstood. People blame the boards
of engineers for laws they don't like.

Two of the areas where these jurisdictions differ is in level of
enforcement and in
exact guidelines for titles. For example, the laws in most jurisdictions
state that
those teaching engineering must be licensed, but only in a few is this
actually
enforced (Texas has enforced this in a somewhat haphazard manner, but in
recent years has been working with engineering schools to get their faculty
licensed). In some jurisdictions the term "professional engineer" is
restricted
but the term "engineer" is not.

Other countries vary a lot. But many countries outside of North America
have closer ties between their governments and the professional societies
and thus rather different mechanisms for recognizing the credentials
of qualified practitioners. Also, in many countries outside North America,
the term "engineer" is viewed as a term describing a technician (less
well educated than a "scientist", for example) and thus the licensing
issues are not associated with the title "engineer"

Dennis J. Frailey                                       voice 972-575-0800
Principal Fellow                                        fax 972-575-6442
Raytheon                                                    pager
972-558-8613
6620 Chase Oaks Blvd                          d-frailey@raytheon.com
MS 8528
Plano, TX 75023 USA

                    "Robert Seletsky"
                    <rseletsky@onboard-sof        To:     "FASE Discussion"
                    tware.com>                    <fase-talk@lyris.ttu.edu>
                                                  cc:
                    05/22/2001 10:05 AM           Subject:     RE: CSEP Program - Information
                    Please respond to             regarding program change (fwd)
                    "FASE Discussion"

I beieve every state has its own engineering licensure laws, but here is
part of the Texas Engineering Practice Act from the website
http://www.tpbe.state.tx.us

Section 1. This Act shall be known and may be cited as "The Texas
Engineering Practice Act."

Section 1.2. PROHIBITED ACTS AND CONDUCT. (a) From and after the effective
date of this Act, unless duly licensed in accordance with the provisions of
this Act, no person in this
state shall:

(1) Practice, continue to practice, offer or attempt to practice
engineering
or any branch or part thereof.

(2) Directly or indirectly, employ, use, cause to be used or make use of
any
of the following terms or any combinations, variations or abbreviations
thereof as a professional, business or
commercial identification, title, name, representation, claim, asset or
means of advantage or benefit: "engineer," "professional engineer,"
"licensed engineer," "registered engineer,"
"registered professional engineer," "licensed professional engineer,"
"engineered."

(3) Directly or indirectly, employ, use, cause to be used or make use of
any
letter, abbreviation, word, symbol, slogan, sign or any combinations or
variations thereof, which in any manner
whatsoever tends or is likely to create any impression with the public or
any member thereof that any person is qualified or authorized to practice
engineering unless such person is duly
licensed under and practicing in accordance with the provisions of this
Act.

Section 1.3. Every person licensed by the Board to engage in the practice
of
engineering shall in the professional use of his name on any sign,
directory, listing, contract, document,
pamphlet, stationery, letterhead, advertisement, signature, or any other
such means of professional identification, written or printed, use one of
the following legally required
identifications: Engineer, Professional Engineer or P.E.

It seems to me that, at least in Texas, the use of any title by an
unlicensed person containing "engineer" would be illegal.
Do other countries treat the "engineer" title in a similar manner?

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Tue, 22 May 2001 19:55:01 -0500
From: "Dennis J. Frailey" <d-frailey@raytheon.com>
Organization: Raytheon Company

"Hensley, David W" wrote:
>
> Dennis J. Frailey wrote
> >
> > To extend this to software, if someone were a "certified
> > software engineer" their title might be something like
> > "Fellow of the International Society of Software Engineers".
> >
> >
>
> So any speculation on the reaction of state engineering boards to displaying
> a title of "Fellow of the International Society of Software Engineers" to
> the public? Sure sounds good--mom would be proud ;)
>
> Cheers,
>
> Dave
>
I am quite sure this would be fine with them.
Just as today one can say one is a Fellow if the IEEE
with no problems from the PE community.
This issue has already been discussed at length with them.
What they object to is saying you are "an engineer".
It seems subtle but it works.

DJF
--
Dennis J. Frailey                D-Frailey@Raytheon.com (email)
Principal Fellow                 972-575-0800 (voice)
Raytheon Company                 972-575-6442 (fax)
6620 Chase Oaks Blvd             972-558-8613 (pager)
MS 8528    PSK9
Plano, TX 75023

Subject: Re: CSEP Program - Information regarding program change (fwd)
Date: Wed, 23 May 2001 06:45:49 -0700
From: "Hensley, David W" <david.hensley@compaq.com>

> Dennis J. Frailey wrote
>
> I am quite sure this would be fine with them.
> Just as today one can say one is a Fellow if the IEEE
> with no problems from the PE community.
> This issue has already been discussed at length with them.
> What they object to is saying you are "an engineer".
> It seems subtle but it works.
>
> DJF

Thanks. Makes sense, and it explains why we seem to have job categories and
even billboards with "software engineer" on them without issues with the
board. Well, hopefully the new CSEP title will be something along these
lines.

Cheers,

Dave

Dave Hensley, P.E.           Compaq Telecommunications
Senior Solutions Architect   1255 West 15th
Wireless Solutions           MS 3
Phone: 972.516.6295          Plano, TX 75075-7270
Fax:   972.516.6383          Email: david.hensley@compaq.com

Subject: Essay on SW Engineering
Date: Tue, 23 Oct 2001 13:40:02 -0500
From: "Vicki L. Almstrum" <almstrum@cs.utexas.edu>

I wanted to call everyone's attention to the following article
published in the issue of ACM Ubiquity that I received earlier today.

-- Vicki

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ubiquity: A Web-based publication of the ACM
Volume 2, Number 33, Week of October 22, 2001

In this issue:

View --

What is Software Engineering?

The name implies scientific rigor, and opens software engineering to the
charge that it is a pseudo-science flying under false colors.
By Bill Curran
http://www.acm.org/ubiquity/views/b_curran_1.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
----------------------------------------------------------------------
Vicki L. Almstrum, Ph.D       tel: +1-512-471-9737
Dept of CS, TAY 2.124 (C0500)      +1-512-471-7316 (dept. switchboard)
Univ. of Texas at Austin      fax: +1-512-471-8885
Austin, TX 78712 USA         email: almstrum@cs.utexas.edu
office: TAY 4.118             http://www.cs.utexas.edu/users/almstrum/

Subject: Re: Essay on SW Engineering
Date: Tue, 23 Oct 2001 15:37:58 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Organization: Mercer University School of Engineering

Vicki,

Thanks for alerting us to this.

1. Engineering is not science, not in any area of engineering nor in any
area of science. Engineering science (such as physics for electrical and
mechanical engineering) does involve rigor, but EE and ME are not sciences.
The statement, "The name implies scientific rigor ..." is incorrect, and
reinforces the notion that traditional computer science does not understand
the difference between science and engineering. Statements such as, "Of
course SE is an artificial science ..." offer yet more reinforcement for
this notion.

2. Engineering involves engineering practice. Practice in any branch of
engineering may be more or less rigorous, frequently less. That software
engineering should involve non-rigorous practice demonstrates that software
engineering has much in common with traditional engineering. (There are
differences between traditional engineering and software engineering, but
they are not addressed in this paper. Little about engineering is addressed
in this paper.)

3. "If we pick up an engineering book on how to design an automobile
engine, we do not find sections on the waterfall model or the spiral model
that we find in SE texts." No, but you would find them in Industrial
Engineering and Engineering Management. Engineering uses what it needs for
the task at hand. The actual design process for automobile engines surely
involves process model issues. Do automotive engineers develop prototypes?
Of course they do.

Paul

"Vicki L. Almstrum" wrote:

> I wanted to call everyone's attention to the following article
> published in the issue of ACM Ubiquity that I received earlier today.
>
> -- Vicki
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ubiquity: A Web-based publication of the ACM
> Volume 2, Number 33, Week of October 22, 2001
>
> In this issue:
>
> View --
>
> What is Software Engineering?
>
> The name implies scientific rigor, and opens software engineering to the
> charge that it is a pseudo-science flying under false colors.
> By Bill Curran
> http://www.acm.org/ubiquity/views/b_curran_1.html
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
> ----------------------------------------------------------------------
> Vicki L. Almstrum, Ph.D       tel: +1-512-471-9737
> Dept of CS, TAY 2.124 (C0500)      +1-512-471-7316 (dept. switchboard)
> Univ. of Texas at Austin      fax: +1-512-471-8885
> Austin, TX 78712 USA         email: almstrum@cs.utexas.edu
> office: TAY 4.118             http://www.cs.utexas.edu/users/almstrum/
>
> ---
> You are currently subscribed to fase-talk as: macneil_pe@MERCER.EDU
> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.ttu.edu

--
-----------------------------------------------------------------------
Paul E. MacNeil, Ph.D.
Associate Professor, Software Engineering Program Director
School of Engineering
Mercer University
1400 Coleman Ave. (for standard deliveries)
1200 Prince St. (for overnight and FedEx deliveries)
Macon, Georgia 31207
tel: (478) 301-2185 [note new area code]
fax: (478) 301-2732
macneil_pe@mercer.edu
http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
http://www.accucomm.net/~macneil/index.html

Subject: Re: Essay on SW Engineering
Date: Tue, 23 Oct 2001 14:53:37 -0500
From: Laurie Werth <lwerth@cs.utexas.edu>

There is a forum on the Ubiquity page - comments there may be
seen by more people. So far, it is one for and two against
the author's apparent point that Engineering is equivalent to Science.

Laurie Werth

Subject: Re: Essay on SW Engineering
Date: Tue, 23 Oct 2001 16:19:57 -0500
From: Dennis J Frailey <d-frailey@raytheon.com>

I'm not sure where this guy is coming from, but he
seems to be another computer scientist confusing science
and engineering and demonstrating his lack of knowledge
of what he is talking about.

Regards, Dennis J. Frailey

"Vicki L. Almstrum" wrote:
>
> I wanted to call everyone's attention to the following article
> published in the issue of ACM Ubiquity that I received earlier today.
>
> -- Vicki
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ubiquity: A Web-based publication of the ACM
> Volume 2, Number 33, Week of October 22, 2001
>
> In this issue:
>
> View --
>
> What is Software Engineering?
>
> The name implies scientific rigor, and opens software engineering to the
> charge that it is a pseudo-science flying under false colors.
> By Bill Curran
> http://www.acm.org/ubiquity/views/b_curran_1.html
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
> ----------------------------------------------------------------------
> Vicki L. Almstrum, Ph.D       tel: +1-512-471-9737
> Dept of CS, TAY 2.124 (C0500)      +1-512-471-7316 (dept. switchboard)
> Univ. of Texas at Austin      fax: +1-512-471-8885
> Austin, TX 78712 USA         email: almstrum@cs.utexas.edu
> office: TAY 4.118             http://www.cs.utexas.edu/users/almstrum/
>
> ---
> You are currently subscribed to fase-talk as: d-frailey@raytheon.com
> To unsubscribe send a blank email to leave-fase-talk-3002Q@lyris.ttu.edu

--
Dennis J. Frailey                D-Frailey@Raytheon.com (email)
Principal Fellow                 972-575-0800 (voice)
Raytheon Company                 972-575-7701 (fax)
6620 Chase Oaks Blvd             972-558-8613 (pager)
MS 8528
Plano, TX 75023

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 07:14:36 -0700
From: "Hensley, David W" <david.hensley@compaq.com>

Probably explains why some of our new grads still have more expertise in
compiler and graph theory than than they do in engineering software
products.

Is this one of the last roars of the dinosaurs, or are there a lot of
people still out there that think this way?

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 11:10:15 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Organization: Mercer University School of Engineering

We have been trying to convince computer scientists that computing needs
and has its own engineering, and that that engineering already exists and is
called software engineering and computer engineering. We haven't made much
headway.

Perhaps we haven't made much headway because we assume that the CS people
understand science and engineering. There is a growing body of anecdotal
evidence that many do not.

Secondarily, another obstacle may be the shock CS people feel when they
see the relatively small body of true CS knowledge that SEs need. But this
phenomenon is common to the other science and engineering disciplines, too.
As a sophomore physics major, I was shocked that the engineering majors
disappeared from the common physics courses when we reached modern physics.

As a faculty member in an engineering school, involved in curriculum
development, it is strikiing to me that most engineers learn approximately
zero post-nineteenth-century physics. But I can see that the reasoning behind
this decision is sound. Most engineers would have little use for 20th century
physics. In order to learn some modern physics, they would have to give up
curriculum subjects that they will use. Including modern physics would be a
bad decision.

Computer scientists may face a similar issue when they see that most SEs
need no theory of computing, etc., and that the SEs are better of learning
more SE practice and less pure CS. Unlike natural scientists, CS people are
not in a culture that helps them to see the reasoning behind this decision.
Perhaps we can help.

What is the relationship of CS to SE? A practice-oriented point of view
is that CS provides SE with infrastructure. What are programming languages,
exception handling and operating systems to a practicing software engineer?
These products of computer science are infrastructure, tools used to build
projects. The theory of these is of great interest to CS. It is of little
import to the daily work of an SE, much as solid state physics is of little
import to the daily work of an electrical engineer or computer engineer using
CMOS chips.

What can we do to help the CS people to understand:

1. The distinction between science and engineering, and

2. The true nature of the relationship between CS and SE?

Paul

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 11:27:12 -0700
From: Brent Capps <bcapps@hevanet.com>

At 11:10 AM 10/24/2001, Paul E. MacNeil wrote:

My hunch is that resistance to software engineering among some CS faculty and PEs has much to do with fear of technical
obsolescence and erosion of organizational power bases.

The underlying reason that some PEs fight against extending the term 'engineer' to software engineering is that software is becoming
integral to a growing range of products, even those previously considered 'low-tech'. The day is coming when even common
household devices like light switches and electrical outlets will include some embedded software. With software becoming such an
important and promising source for adding value to new products, competitive pressure is forcing manufacturers to rethink their
self-perceptions as 'hardware companies'. The copier industry is one example: for years these were analog devices stood alone
from the network and were the domain of mechanical and electrical engineers. Then the copier industry woke up to the competitive
threat posed by printers. Connecting and managing copiers over computer networks forced many changes in their organizational
structures and product development processes. Now software is acknowledged to be a critical aspect of copier design and
support.

This shift in emphasis has personal consequences for many PEs, who feel threatened by the change and the corresponding loss of
organizational attention, resources, and influence. Rather than swallow their pride and go back to school to update their aging
knowledge base, they instead lash out at what they don't understand (SE.) Resistance to change among CS faculty is just the
academic counterpart of the same general phenomenon.

-----
Brent Capps
Online Education Administrator
Oregon Master of Software Engineering Program
http://www.omseonline.org ---

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 14:46:10 -0400
From: David Luginbuhl <drl@cs.wcu.edu>

I really hate to see this degenerate into an "us" vs. "them" issue and to see computer scientists (whatever people have been meaning)
painted with such a broad brush. I consider myself both a Computer Scientist and a Software Engineer (I teach our Theory course AND
our Software Engineering course), and I don't want to have to "choose sides." I also dispute the assertion that Software Engineers need
no theory of computing, but perhaps that's a side issue.

Let's keep this in perspective -- *one* computer science faculty member has posted something at Ubiquity mis-characterizing software
engineering. At last glance of the forum, he was being firmly cast into the minority. Perhaps there are other CS faculty members at
other schools who agree with this person's viewpoint, but I suspect there are many more (even theoreticians!) who would disagree with
him. Let's not drag them into the fray unnecessarily.

Let's correct this mistaken perspective (as some folks have done quite well), but please don't think this means all "traditional" CS faculty
members need correction or retraining.

_______________________________________________
David R. Luginbuhl              Office: 301-A Stillwell
Department of Math and CS       mailto:drl@cs.wcu.edu
Western Carolina University     Voice: 828 227 3825
Cullowhee, NC 28723            FAX:    828 227 7240
         http://www.cs.wcu.edu/~drl/

-----Original Message-----
From: Brent Capps [mailto:bcapps@hevanet.com]
Sent: Wednesday, October 24, 2001 2:27 PM

At 11:10 AM 10/24/2001, Paul E. MacNeil wrote:

My hunch is that resistance to software engineering among some CS faculty and PEs has much to do with fear of technical
obsolescence and erosion of organizational power bases.

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 15:43:59 -0400
From: Mike McCracken <mike@cc.gatech.edu>

I hope that I can offer an opinion on this topic. To start off with (set
my agenda in the open), I disagree with the original essayist. I think his
heart was in the right place, but he got disconnected somewhere. I've been
working on a paper for the last year trying to describe the differences
between computing education and engineering education. It is tentatively
titled injecting engineering into software engineering. Let me see if I
can distill it to maybe offer some different views on the topic.
1. Engineers are taught differently than computer scientists.
2. Software engineers may or may not be taught differently than computer
scientists, but are not taught like engineers.
3. If we want to put some engineering into software engineering (in this
case via education), we need to adopt some of the ways engineers are
taught. Please note, that doesn't mean I agree with all of Parnas's
claims. In particular, I disagree with his subject matter requirements.
But, I am talking about the pedagogical methods that I think he is seeking
through engineering courses.
Here's how engineers are taught (obviously my view, but I have talked to
engineers about this and they seem to agree).
Engineering education is a process of inculturation (as is most education).
The culture of engineering education has a set of distinct characteristics.
It includes, but is not limited to the following:
Problem solving - Engineers are taught problem solving in a particular
manner. Their problem solving skills are developed through repetitive
solving of problem isomorphs in narrow areas (e.g., circuit analysis, or
thermo, or fluids). Engineering students typically solve well over a 100
problems a semester per class. Obviously, to cope with these numbers the
problems are relatively well defined, and are generally isomorphs of
examples or at least analogically close. This is a means of developing
skill as described by Newell in the Power Law of Learning. Solve enough of
the same or similar problems and over time you will be able to solve them
quicker and better.
Seems to me the closest we come to that in CS is the theory classes. I
don't see that in SE classes.
Obession with accuracy - Engineers are taught that if they miss a unit, or
are off beyond the second decimal point, they will get hammered in their
grading. This is another part of the inculturation into the practice of
engineering. Engineers are careful. Their products can often kill people
if mis-designed. Again I see that type of care in theory classes in CS,
but little of it in SE.
Belts and suspenders - As we all know, engineers approximate and use
heuristics in designing. But to overcome their lack of science (hard to
analyze a structure at the molecular level and accommodate all possible
interactions of that structure), they "overdesign" their artifacts and use
existing designs as models of departure. I don't see that in any CS or SE
classes.

When we graduate engineering students, I would claim they don't know much
about design. Haven't done much, nor been exposed to much. But they do
know how to engineer. They have been inculturated into a practice of care,
analysis, and caution and they have an ability to solve relatively well
defined problems. Given a problem, they will roll up their sleaves and
attack it with vigor. It's just that they don't know how to frame a
problem or understand an ill-structured problem. When they go out into the
world they learn how to design stuff, and industry recognizes and accepts
that (though they complain). Engineering educators have decided that
problem solving is the important stuff their kids need to learn. I
recognize all of the hub bub about changing engineering education, but I
don't see a lot people dumping thermo or circuits for contextualized design.

So where does that bring us? If you agree with what I have said, and if we
want software engineers to behave like engineers, teach them like
engineers. Don't make them take thermo, but make them solve problems,
small problems, lots of problems, until they can solve them in their sleep.
Again, I recongize there is a lot more to engineering education, but this,
at least to me, is one major difference between CS/SE and engineering
education.

Here are two examples. First, someone mentioned IE as similar to SE's
process world. IE is a field unto itself. It was recognized that
manufacturing (where most of IE came from) needed a discipline of process
to succeed. The management folks weren't doing it, and it really seemed
more like an engineering problem and thus IE was born. Of course, most
"real" engineers refer to IE as Imaginary Engineering. Do real engineers
worry about process? Most don't, at least in school. Why is that?
Because they're trying to solve all those dang homework problems. How many
engineering students write specifications for systems, study configuration
management, or model and optimize manufacturing processes?

The second example has to do with our project courses. In SE we obsess
about project courses. Do engineers? More as an afterthought. Maybe we
are doing a better job at teaching than the engineers, but my concerns have
to do with our students knowing the basic skills of problem solving, and
less of whether they can design and build some whiz bang piece of software
in two days or less.

I would propose the following. We have much to learn from both engineering
and computer science. Engineering gives us the discipline (and that
discipline ain't process or PSP) of learning to be careful, exact and
obsessive. Computer science gives us the fundamentals of constructing
computing systems. SE's construct systems, they don't necessarily invent
new ways of constructing systems. The CS folks need to be wild and crazy.
They need to invent new stuff. SE's on the other hand need to wear belts
and suspenders and be crumudgeons. Does that make SE uninteresting or
boring? No way. SE's get to build real systems, CS folks just dream about
them.
Mike

Subject: SE Practice and SE Education
Date: Wed, 24 Oct 2001 16:28:21 -0400
From: "Paul E. MacNeil" <macneil_pe@Mercer.EDU>
Organization: Mercer University School of Engineering

Software engineering was born primarily in industry. SE, as with
traditional engineering, is primarily about practice. Industry presents the
best and the worst of software development and maintenance. With some
exceptions, SE's most useful results come from industry, or from people with
very close connections with industry. Structured analysis and design, OOA& D,
etc., were developed by people in or consulting closely with industry on real
projects.

Industry has a number of SE practitioners who are very good at the practice
of SE. What do they know that enables them to do a good job? What capabilities
do they have that enable them to practice SE well? An SE graduate who had a
significant amount of these capabilities and knowledge would seem to be well
positioned to contribute in the practice of SE. This observation suggests that
looking at good SE practice is a good guide for designing at least some aspects
of SE educational programs.

Looking at industry for this information is one way of avoiding academic
biases in computing education. At present, all I have are anecdotes and
personal observations from my time in industry, and from my interactions with
current industrial practitioners. I see people who know a lot of traditional
computer science who do well, and who do marginally. I see people without much
traditional computer science knowledge who do well and who do poorly. In most
cases, a traditional CS education seems to be better than no computing
education, but I see little correlation between a traditional CS education and
good SE practice.

This point of view suggests a test for whether or not a particular piece of
knowledge or education is really important for SE. If a large number of good SE
practitioners do not have that knowledge or education, then that knowledge or
education is probably not essential for SE practice, even if it is dear to us.
And, knowledge or education that is common to many good practitioners may well
be very important, even if we don't presently care about it.

The knowledge represented by, for example, Steve McConnell's "Code
Complete", Bruce Eckel's "Thinking in C++" or "Thinking in Java", or the "Gang
of Four's" "Design Patterns" seems to make available much good practice from
industry. These are numerous other examples.

Paul

--
-----------------------------------------------------------------------
Paul E. MacNeil, Ph.D.
Associate Professor, Software Engineering Program Director
School of Engineering
Mercer University
1400 Coleman Ave. (for standard deliveries)
1200 Prince St. (for overnight and FedEx deliveries)
Macon, Georgia 31207
tel: (478) 301-2185 [note new area code]
fax: (478) 301-2732
macneil_pe@mercer.edu
http://www.mercer.edu/engineering/GRAD_PROGRAMS/sse.htm
http://www.accucomm.net/~macneil/index.html

Subject: Re: Essay on SW Engineering
Date: Wed, 24 Oct 2001 20:54:10 -0700
From: Steve Tockey <Steve.Tockey@construx.com>

All,
Let me start by voicing support for comments in messages by Paul
E. MacNeil and Mike McCracken. I agree with most of what they say.
But, of course, I have some to add of my own.

I think there's more than one issue wrapped up in this whole
discussion.

The first issue is whether what the typical software professional
is doing on a daily basis can be considered "engineering". IMHO,
I don't think so. I'll explain why below.

Second, I think an important issue is whether what's typically
taught to the typical software-professional-to-be in school can
be considered an engineering education. Again (with a few notable
exceptions), IMHO the answer is no. My explanation follows.

Underneath both of these issues is the simple question, "what does
it mean to be an engineer, anyway?". We can all pontificate on this
to no end, but someone's already addressed this issue. The engineers.
In particular, in the US the Accreditation Board of Engineering and
Technology (aka "ABET") has what I think is a pretty good definition
of engineering:

        "... the profession in which a knowledge of the mathematical and
        natural sciences gained by study, experience, and practice is
        applied with judgement to develop ways to utilize, economically,
        the materials and forces of nature for the benefit of mankind"

DeGarmo et. al. [E. DeGarmo, W. Sullivan, J. Bontadelli, Engineering
Economy, Ninth Edition, Prentice Hall, 1993] paraphrase engineering
as:

"... finding the balance between what is technically feasible
and what is economically acceptable"

Based on this, I think that the third (and somewhat separable issue
from the two above) is whether there _could_ be something called
"Software Engineering" and if so, what should it look like?

I interpret the ABET and DeGarmo definitions as saying that engineering
is based on two basic knowledge areas. Knowledge area #1 is mathematics
and science. This knowledge area is necessary for the engineer to be
able to generate as many theoretically-possible solutions as they
can. The more theoretically-possible solutions considered, the more
likely the best solution is to be in that set.

Knowledge area #2 is all about finding that "best" solution. What
makes it the best? Economics. The best solution is the one with the
highest ROI, the highest Benefit/Cost ratio, the highest Net Present
Value, whatever.

Simply, the best solution is the one that will work (according to the
relevant theory) AND is also the most financially-responsible
option.

So what's this mean for software engineers and software engineering
education? It means that computer science is surely relevant. So is
discrete math. That's all the theory stuff that a software engineer
should be considering when coming up with possible solutions. But it
also means that they need to know about economic decision making.
Things like the time value of money (interest), cash flows, NPV and
ROI, taxes, inflation, useful life, etc.

I have yet to run into more than a mere handful of (highly-paid, no
less) software professionals that even knew what an ROI really means,
let alone how to go about calculating one. How can someone claim to
be providing economical solutions to real-world problems when they
don't even know how to make economically-based decisions?

So, I don't think what most practicing software professionals do on
a daily basis should, or even could, be called engineering. Neither
do I think that most college and university curricula even come close
to being a legitimate engineering education (again, a few notable
exceptions here). The old strategy of "proof by repeated assertion"
doesn't work. Simply calling it engineering doesn't make it (whatever
it is) engineering. Period.

But I do surely belive that there can and should be a legitimate
discipline called "software engineering". And I think it can and should
be defined and described in a way that the recognized engineering
disciplines will welcome it rather than resist it. But it takes a
solid understanding of what "engineering" really is before it will
happen.

My proverbial two cents,

-- Steve
VP of Consulting

Construx Software
11820 Northup Way, Suite E200
Bellevue, WA 98005-1926
(425) 372-0106
http://www.construx.com
Steve.Tockey@Construx.com

> -----Original Message-----
> From: Vicki L. Almstrum [mailto:almstrum@cs.utexas.edu]
> Sent: Tuesday, October 23, 2001 11:40 AM
> To: FASE Discussion
> Subject: Essay on SW Engineering
>
>
> I wanted to call everyone's attention to the following article
> published in the issue of ACM Ubiquity that I received earlier today.
>
> -- Vicki
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Ubiquity: A Web-based publication of the ACM
> Volume 2, Number 33, Week of October 22, 2001
>
> In this issue:
>
>
> View --
>
> What is Software Engineering?
>
> The name implies scientific rigor, and opens software
> engineering to the
> charge that it is a pseudo-science flying under false colors.
> By Bill Curran
> http://www.acm.org/ubiquity/views/b_curran_1.html
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
> ----------------------------------------------------------------------
> Vicki L. Almstrum, Ph.D       tel: +1-512-471-9737
> Dept of CS, TAY 2.124 (C0500)      +1-512-471-7316 (dept. switchboard)
> Univ. of Texas at Austin      fax: +1-512-471-8885
> Austin, TX 78712 USA         email: almstrum@cs.utexas.edu
> office: TAY 4.118             http://www.cs.utexas.edu/users/almstrum/
>
> ---
> You are currently subscribed to fase-talk as: stevet@construx.com
> To unsubscribe send a blank email to
> leave-fase-talk-3002Q@lyris.ttu.edu
>

Subject: Re: Essay on SW Engineering
Date: Thu, 25 Oct 2001 10:53:25 -0500
From: Dennis J Frailey <d-frailey@raytheon.com>

> Steve Tockey wrote:
>
...
> The first issue is whether what the typical software professional
> is doing on a daily basis can be considered "engineering". IMHO,
> I don't think so. I'll explain why below.
I agree with you. But there is a class of people who are doing
so, and it is those whom I consider to be software engineers.
One of the main objections to what has been happening in trying
to professionalize software engineering is that those who do
not practice it as "engineering" object to losing the title
"software engineer" by which they have come to identify themselves.

This is not all that dissimilar to the manner in which medical
practitioners of various kinds
resisted formalization of the medical profession back in the
early days of modern medicine.
>
> Second, I think an important issue is whether what's typically
> taught to the typical software-professional-to-be in school can
> be considered an engineering education. Again (with a few notable
> exceptions), IMHO the answer is no. My explanation follows.
I agree with this is well, but there are serious efforts to change
this. Once again, opposition seems to come from those quarters
that are not equipped or prepared to step up to the bar here, but
who do wish to have the enrollments associated with students seeking
a career in software engineering.
>
> Underneath both of these issues is the simple question, "what does
> it mean to be an engineer, anyway?".
I think your analysis is good here, but with a couple of observations.

> "... finding the balance between what is technically feasible
> and what is economically acceptable"
IMHO, as a former engineering school faculty member and as a
practitioner
in a major engineering company who has interacted with many engineering
schools on student projects and curriculum development, I have found
that the latter, although critical to practicing engineers, is
mightily resisted by most engineering school faculty. In short, one
could argue that while the "balance" mentioned above is a critical
factor in defining engineering, most engineering schools do not do a
very good job of teaching this aspect of engineering. Instead, we in
industry need to teach it to them after they start working. And those
who go to smaller firms often never learn it well at all. I bring
this up to point out that just about anyone can say "x is part of
engineering and x is not taught in field Y, therefore field Y is not
really engineering." By that measure, one could argue that there
is very little true engineering education going on,
even in the accredited engingeering programs.
>
...
> Knowledge area #1 is mathematics
> and science. This knowledge area is necessary for the engineer to be
> able to generate as many theoretically-possible solutions as they
> can. The more theoretically-possible solutions considered, the more
> likely the best solution is to be in that set.
For what it is worth, I find that few practicing engineers really
do this.
>
...

> I have yet to run into more than a mere handful of (highly-paid, no
> less) software professionals that even knew what an ROI really means,
> let alone how to go about calculating one.
Exactly! This is one of the reasons why I claim that most practicing
software developers are not software engineers.

...
> But I do surely belive that there can and should be a legitimate
> discipline called "software engineering". And I think it can and
> should
> be defined and described in a way that the recognized engineering
> disciplines will welcome it rather than resist it.
Exactly what has been underway for several years, despite being
sabotaged by ACM Council a while ago.

Regards, DJF
--
Dennis J. Frailey                D-Frailey@Raytheon.com (email)
Principal Fellow                 972-575-0800 (voice)
Raytheon Company                 972-575-7701 (fax)
6620 Chase Oaks Blvd             972-558-8613 (pager)
MS 8528
Plano, TX 75023

Return to FASE main page