sss ssss rrrrrrrrrrr
ssss ss rrrr rrrr
sssss s rrrr rrrr
ssssss rrrr rrrr
ssssssss rrrr rrrr
ssssss rrrrrrrrr
s ssssss rrrr rrrr
ss sssss rrrr rrrr
sss sssss rrrr rrrr
s sssssss rrrrr rrrrr
+===================================================+
+======= Quality Techniques Newsletter =======+
+======= June 2003 =======+
+===================================================+
QUALITY TECHNIQUES NEWSLETTER (QTN) is E-mailed monthly to
Subscribers worldwide to support the Software Research, Inc. (SR),
TestWorks, QualityLabs, and eValid user communities and other
interested parties to provide information of general use to the
worldwide internet and software quality and testing community.
Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of QTN provided that the
entire document/file is kept intact and this complete copyright
notice appears with it in all copies. Information on how to
subscribe or unsubscribe is at the end of this issue. (c) Copyright
2003 by Software Research, Inc.
========================================================================
Contents of This Issue
o Software Engineering is Illegal (Part 2 of 2), by Boris
Beizer, Ph. D.
o Prof. Dave Parnas Writes In Response to Part 1 of Beizer's
Article.
o Dr. Beizer's Response to Parnas' Comments
o eValid Site Comparisons, WebStore Special, Training
o Call for SWEBOC Reviewers
o eValid WebSite HealthCheck Offer
o Nordic Conference on Web Services
o QTN Article Submittal, Subscription Information
========================================================================
Software Engineering is Illegal (Part 2 of 2)
by
Boris Beizer
Note: This article is taken from a collection of Dr.
Boris Beizer's essays "Software Quality Reflections" and
is reprinted with permission of the author. We plan to
include additional items from this collection in future
months.
Copies of "Software Quality Reflections," "Software
Testing Techniques (2nd Edition)," and "Software System
Testing and Quality Assurance," can be purchased
directly from the author by contacting him at
.
We're concerned with quality, so we should ask what constitutes a
passing grade for the exam. It varies from state to state, but
generally, 70% will do it. However, because of the way the test is
scored, that actually means that you only have to get half the
questions right. How's that for a quality standard? How's that for
protecting the public good? Those so-called engineers only have to
be right half the time. The instructions in a popular cram book
goes on to say that if you don't know, don't leave the answer blank.
It's a multiple choice exam and no points are taken off for wrong
answers. Random guesses will get you 20% of the way to a passing
grade. When in trouble or in doubt, guess!! You'll only kill
someone 80% of the time. So much for the quality concerns and the
engineering ethics that these exams teach to young aspirants. Could
we, the illegal Software Engineers, afford to guess? Could we sell
software that was only 50% right? Could those hard-head engineers
use our software if that was our standard?
4. A Real-World Message.
There's a real-world message to be contrasted with the mythical
message perpetuated by the so-called professional engineers. The
examinations tell the story. The exams require a very broad base of
knowledge and techniques across the entire range of engineering,
excluding of course, Electronics, Computers, and Software
Engineering. You need a smattering of electrical circuits, fluid
mechanics, thermodynamics, statics, dynamics, chemistry, strength of
materials, economics, etc. That was fine in the last century, and
even up to the 30's and 40's when it was possible for a hard-
working, hard-studying engineer to encompass that body of knowledge:
there just wasn't that much of it to learn. For a 19th century
engineer, it was proper and more important, it was possible, to get
a smattering of knowledge across the entire field.
That once noble aspiration is of course, ridiculous today. I've
devoted 40 years to the Software Engineering profession and there
are huge areas within Software Engineering of which I am almost
completely ignorant beyond the level of a technological layman. To
have effective broad knowledge within the software field alone would
require reading, digesting, and internalizing every issue of say,
ACM Computing Surveys. I don't have the time for that, or the need.
At best, I read the summaries in that journal and the one-out-of ten
surveys that most apply to my sub-sub-sub specialty, Testing and
Quality Assurance. And I spend a lot more time in self-educational
pursuits than most working Software Engineers because my business is
technology transfer. How about the rest of you? We have to run
like hell to keep up with an explosively evolving technology. We
must prioritize our time and allocate our self-education, or else
there's no time to do Software Engineering as contrasted with
studying it.
It's the same in school. Employers don't want renaissance men.
They want people adept in C++, or Windows, or ATM, or what have you.
Just try to sell your superficial knowledge of strength of materials
or fluid dynamics (which you learned at the expense of deeper
software knowledge). You know the answer. If they need an expert
in thermodynamics, they'll hire a real one to work with you and not
someone with an operationally useless smattering of key words.
The PE's ideal of the mythological engineering renaissance man is a
century out of date. It flies in the face of technological
realities. It serves only one purpose to maintain an entrenched
oligarchy intent only on perpetuating their self-interest at the
public's expense. How has the "Professional Engineering" oligarchy
maintained the myth? By simply saying that anything that doesnt fit
their myth, such as Software Engineering, is not engineering.
5. Software Engineering Versus Engineering Software.
My research led me to examine all recent periodicals and journal
articles that had both "software" and "engineering" in the title or
abstract. There were tens of thousands such articles in the past
decade and even thousands in just the last two years. The "Software
Engineering" articles appeared in all the journals you and I read.
But they were few in number compared to the "Engineering Software"
articles in the traditional engineering literature. I checked that
by eliminating from the search all computer, software, and related
journals; looking only at the traditional mechanical, civil,
chemical, etc. periodicals. Guess what the hot topic is, folks?
"Engineering Software," of course. More articles on Engineering
Software than almost any other engineering topic. Engineering
software written by all those illegal Software Engineers. So you
see, ours is a problem of permutations. You can write "Engineering
Software" as long as you don't do "Software Engineering." The one
permutation is legal, the other is not.
Doesn't it give you the willies to realize that all that software on
which our hard-hat brethren depend, the software that calculates the
right size for structural steel in our buildings, that's used to
design the controls for the aircraft on which we fly, that
calculates the radiation dosages to give cancer patients, that keeps
us from having a weekly Chernobyl accident -- doesn't it give you
the willies to realize that all that "engineering software" could
have been written by a bunch of high-school kids? It must have been
written by high school kids because we professionals don't exist and
because YOU CAN'T BE A SOFTWARE ENGINEER even if you write the
engineering software used by those "real" engineers.
6. Why Should We Care?
Why should we care what a self-perpetuating ossified oligarchy
decrees what is, by their aboriginal patriarchal standards, to be or
not to be called "Engineer?" We know what we are, what we do, how
we do it, and we'll keep on doing it and calling it "Software
Engineering" despite all the witless laws on the books. Those laws
are as irrelevant as the statutes in some states that, for example,
requires every automobile to be preceded by a man with a lantern who
clangs a bell at regular intervals. Ignore the moronic laws and
concentrate on doing an ever-better job.
"Let it be." you say, "It's just semantics." You wouldn't dream of
specifying the concrete for an elevated freeway or the codes for
earthquake protection. You wouldn't dream of signing-off on the San
Francisco Freeway even though many of you might know a hell-of-a-
lot more about concrete structures than they know about structured
software. If they want to be irrelevant in the post-industrial
world and not recognize our kind of engineering, it's their loss.
We don't tell them how to link chains, they don't tell us how to
link objects. That would be nice, but it doesn't work that way.
These men, in their almost infinite arrogance, do presume to
regulate how we do software. There is real power for the PE in
those laws and real danger to the public. And sooner or later you
will run afoul of these archaic statutes:
1. Legally, in most states, only a PE can give expert testimony in
court on engineering projects. A smart lawyer might get me
disqualified from testifying on the adequacy of software testing
methods, for example. I'm sure we have a few PE's among our
ranks, but very few expert in Software Engineering ever advertise
that fact.
2. Legally, in most states, only a PE can call themselves an
"Engineering Consultant" and only a PE can advertise as such.
3. In many civil projects-, especially when funded by state or
municipal agencies, where there is a software content, you will
have to pay a useless "consultant" who doesn't understand one
word of what he's approving, to legally sign-off on your project.
And there's no end of PE's willing to prostitute themselves for a
fee. It's a waste of public money as far as software is
concerned.
4. We should care because whenever a software-ignorant civil or
mechanical engineer hires a bunch of high-school kids to do
software for one of their projects: and when, as expected, the
bottom falls out, it is we, the real Software Engineers, who take
the flack. It doesn't matter if the software was written by
amateurs or by engineers who know nothing about our profession
and methods. We, the professionals, are blamed for every fiasco
that involves software.
5. The main reason we should care, however, is because the public
is harmed by these stupid laws. We should care because in Civil
Engineering project after project with a high software content,
signed-off by so-called "professional engineers," we see the
public good damaged by hopelessly inadequate software miscrafted
by amateurs no better than high-school kids instead of by
professionals, to professional standards, and under professional
quality assurance and quality control methods. Look at Peter
Neumann's column in ACM-SIGSOFT and ask of the fiascos described
therein how many were caused by unprofessional software
developers working under the guidance and control of a so-called
"professional engineer." I'll bet on the Denver Airport baggage
handling system software for a start.
7. What to Do?
Ever since Barry's letter was published in ACM SIGSOFT (that
notoriously illegal journal), there's been an initiative afoot to
rectify this situation. But frankly, as laudable and as important
as that initiative is, it isn't going to work. It isn't going to
work because it is based on the false premise that the issue has to
do with technology and that there are rational criteria for getting
Software Engineering recognized and legalized. The key components
of the initiative are: (1) define a body of knowledge, (2) define
recommended practices, (3) establish a code of ethics, (4) establish
certification/accreditation guidelines, and (5) define a curriculum.
I'm for all of these because our profession would be improved by
them, but...
But the initiative won't succeed. It won't succeed because it's
based on an attempt to work within the system! "The System," being
of course, the entire self-interested, exclusionary, PE hierarchy.
It will fail because it doesn't recognize that the key issues are
political and economic rather than technical. If we, by magic,
created a consensus on all five of the above and presented it to
that ossified oligarchy, it wouldn't matter. They would simply keep
on insisting that we do not exist and that what we do can be done by
high-school kids.
It's a problem of technological politics that demands political
solutions. Here are some ways to do that:
1. Start the political initiative in California, where we have the
most practitioners and votes. Follow up in other states with
similar attributes such as Washington (Seattle area), Texas,
Massachusetts, Oregon, Florida, Virginia, and Maryland. Don't
bother with congressmen. Write to your state legislator and
convey to him or her:
a. How many votes Software Engineers have in their district
compared to the number of votes by so-called Professional
Engineers. We outnumber them by 10:1.
b. How many jobs these laws might be costing and the advantage it
gives to foreign suppliers not bound by such laws.
c. Any instance you know of in which a traditional engineering
project in your state with a crucial software content was
signed off by a so-called Professional Engineer to the
detriment of the public's interest. Do some creative whistle
blowing.
d. Ask why you can't get a license to practice your profession.
Ask why it is with N thousand voting practitioners in his or
her district and only K dozen voting PE practitioners, only
the PE's can get a license to practice engineering.
2. A class action suit against ABET, NSPE, and NCEE based on their
possible violation of the Sherman Anti-Trust Act.
3. Let's get Bill Gates and Dilbert interested.
4. Form our own PAC.
5. Software Engineering is the single largest group within ACM and
IEEE. Push these notoriously apolitical entities into action.
Flex your muscles.
6. Join forces with the next largest group of engineers, also
effectively excluded, the Electronics Engineers. They were
teed-off with the PE's forty years ago and they still haven't
been totally legitimatized. The barrier for them is that first
irrelevant exam because they have a chance of passing the
Principles and Practices exam if they can get by the so-called
fundamentals.
7. When you next make a contribution to your alumnus association,
demand to know when your school intends to have an accredited
program in Software Engineering under that name. Don't accept
any obfuscatory academic-administrative BS and excuses for an
answer. Let them know that your annual donation will be going to
the first university that has a legitimate department teaching
Software Engineering under that name.
8. Let the politicians, the lawyers, the hard-hat engineers, all
know that:
YOU ARE A SOFTWARE ENGINEER!!!
========================================================================
Prof. Dave Parnas Writes
In Response to Part 1 of Beizer's Article.
Note: This is Prof. Parnas Response to Part 1 of the Beizer Article,
which appeared last month. Part 2 of the article appears above.
Dear SR.
I am surprised that Dr. Beizer would want his 1995 essay published
in 2003. A great deal has happened in this area since that essay
was written. Among other things there are now several accredited
engineering programs specializing in software development in Canada
and the US and the Engineering profession has made it clear that it
is open to emerging disciplines including Software Engineering.
The situation is quite simple. In many jurisdictions, Engineering
is, by law, a self regulating profession just as Medicine is. The
regulatory bodies for both professions are duty bound to make sure
that the public is able to easily distinguish between qualified and
unqualified practitioners. The easiest way to do that is by means
of a protected title. The title is given to those who prove
(through exams and experience) that they are qualified and removed
from those who do not practice properly. Just as I would not want
to have to do a reference check when I need a medical doctor, we
should not have to study academic records and activity records when
selecting someone to build a bridge or other structure. When I see
that someone is an M.D., I know that he/she has had a basic medical
education, appropriate years of apprenticeship, has passed certain
exams, and will have her/his license removed should he/she be found
to have been negligent. I should be able to identify qualified
people easily in any profession that builds critical products.
The title is enforced primarily in situations where its use could
cause confusion. If someone is offering Engineering services to the
public or may be perceived to be doing so, they must be entitled to
use the title.
The title is often not enforced when there is no possibility of
confusion. For example, nobody will assume that the driver of a
train is qualified to offer engineering design services to the
public. The use of the term "Sanitary Engineer" is more likely to
induce a bad joke ("the rest are dirty engineers") than any
misunderstanding. However, the use of the title "Software Engineer"
is likely to cause a non expert to believe that the person has
proven qualifications and could be a cause of confusion. There is
justification for enforcing the title in such cases. I believe that
the Engineering regulatory authorities have been negligent when they
allowed the title "Software Engineer" to be used without
restriction.
The present situation is far from ideal. The exams and other
restrictions were developed for very different professions. There
are two approaches to approving it, but neither one is advanced by
the scathing cynicism expressed in Beizer's article. One approach
would be for such groups as ACM to work with the Engineering
regulatory authorities to improve the relevance of the tests. I
have been disappointed by their refusal to do so. The ACM seems to
be taking the position that we have to know how to produce perfect
software before we can begin to distinguish between reasonably
competent software developers and others who present themselves as
competent. If we had taken that position about roads, I might be
designing mountain bridges without any qualifications at all.
The second approach would be to choose a different title and set up
a meaningful qualification procedure for professional software
developers.
Doctors of Medicine have not been able to keep other types of
professionals from offering healing services. However such other
approaches as Chiropractry have had to use a different title so that
nobody will believe that they are medical doctors. There is no
reason why professional software developers have to use the term
"Engineer". Surely we have enough imagination to find a term that
could not cause confusion. However, we must find the appropriate set
of standards. Here I have been disappointed too. Although there
are efforts to identify a core body of knowledge that should be
possessed by every professional software developer, the proposals
are not very good and have failed to identify the "core" body of
knowledge that should be possessed by every software developer.
Instead they are including folklore and technology as if they were
fundamental principles.
Instead of writing scathing articles because the Engineers won't let
us use their title without proving our competence, we should be
either helping the legally established regulatory authorities to do
a better job or starting a parallel system, with equally high
standards, of our own.
Dave Parnas
Prof. David Lorge Parnas, P.Eng. (Ontario)
Director of the Software Quality Research Laboratory
SFI Fellow, Professor of Software Engineering
Department of Computer Science and Information Systems
Faculty of Informatics and Electronics
University of Limerick
Limerick, Ireland
========================================================================
Dr. Beizer's Response to Parnas' Comments
Note: This is Dr. Beizer's response to Prof. Parnas' Response to
Part 1 of Beizer's Article
> I am surprised that Dr. Beizer would want his 1995 essay published
> in 2003. A great deal has happened in this area since that essay was
> written. Among other things there are now several accredited
> engineering programs specializing in software development in Canada
> and the US...
As far as I know, only Texas (as mentioned in the essay) has
accredited software engineering programs under that name. If there
are other states that permit software engineering by that name, I
may have missed them and will be glad to acknowledge their entry
into the 20th century. As for Canada, I don't know the situation
regarding the legality of software engineering there -- but then, my
essay was aimed at rectifying this ludicrous state of affairs the US
-- not in Canada. As for being germane today, very little has
changed since 1995. The title "Software Engineer" is still not a
legal title in all but a few (one?) US state and the various
engineering accreditation boards have yet to come up with
examinations and protocols that would accept even a minority of
currently practicing, competent, software engineers under that
title.
I'm just a mite puzzled about the use of that title by Parnas. He
doesn't hesitate to call himself a "professional engineer" and to
use that title in his signature block. Nor does he seem to be shy
about calling himself a "Professor of Software Engineering." Does
he mean that those of us who do not have a PE license should seek to
call ourselves something else? I am puzzled because he seems to
suggest in his rebuttal that we should drop our claim to the
"engineer" title -- but he will continue to use it -- because he is
a software engineer -- or at least teaches it. Or is this title to
be permitted only for Canadian software engineers? Yet, he urges
us Americans to seek accreditation under some other "imaginative"
title. Or is he urging us to emigrate to Canada so that we can
legally practice our profession, as does he, under that name?
Parnas calls Software Engineering an "emerging discipline." By my
reckoning, it is over fifty years old. We've been calling it
"Software engineering", by that name, among ourselves and in the
literature for almost forty of those fifty years. So what's this
"emerging" nonsense? What's this "emerging" thing when we routinely
deal with levels of complexity and create products whose work-hour
content makes most traditional engineering projects seem like kid
stuff?
Parnas summarizes the reasons that some kind of licensure for
software is desirable. I and others, have been trying for over
forty years to get some kind of meaningful, germane, recognized
professional certification in place. And we have been thwarted at
every step by entrenched engineering professional organizations --
among others. But I agree with much of what he has to say:
> "The regulatory bodies for both professions are duty bound to make
> sure that > the public is able to easily distinguish between qualified
> and unqualified practitioners."
>
>"The title is given to those who prove (through exams
> and experience) that they are qualified and removed from those who
> do not practice properly"
>
> "The present situation is far from ideal. The exams and other
> restrictions were developed for very different professions."
>
> "One approach would be
> for such groups as ACM to work with the Engineering regulatory
> authorities to improve the relevance of the tests. I have been
> disappointed by their refusal to do so."
Now we get to the points of fundamental disagreement.
> "Instead of writing scathing articles because the Engineers won't
> let us use their title without proving our competence, we should
> be either helping the legally established regulatory authorities to
> do a better > job or starting a parallel system, with equally high
> standards, of our own. "
Parnas suggests that we try to construct a parallel system under a
different name. We should also try to help the regulatory
authorities to do a better job, etc. But we should not resort to
sarcasm -- especially "scathing sarcasm." Where has he been the
past forty or so years? Apparently not in the same software
universe in which I have been. My sarcasm was in direct response
to four decades of inaction and insignificant progress toward any
kind of meaningful licensure -- despite constant efforts by many of
us, trying to act nicely and within the establishment, to get
meaningful recognition. The sarcasm was -- and is -- intended to
shame the US establishment into a recognition of Software
Engineering comparable to that which exists in other countries. I
believe that my sarcasm has been in a small way, instrumental in
nudging American licensure establishments (e.g., ABET) toward a more
realistic recognition of the facts of Software Engineering, as they
are. Yes, there has been some (minuscule) progress (e.g., Texas)
-- but it is still glacial. And the public is still ill-served
because we do not yet have legally meaningful professional standards
and regulations in place.
Some people in our profession do not consider themselves to be
"Engineers." But I and many others came out of more traditional
engineering disciplines and have a philosophical point of view that
is embedded in those older disciplines. We speak of software
engineering, of course, but also of system and software architecture
-- in the original meaning of the word "arkitekton" meaning, "master
builder." Why should we rescind our just claim to the titles of
engineers and architects? Why should we deny the philosophical and
ethical roots that many of us have in the earlier engineering
professions? If forty or fifty years of practice hasn't "proven
our competence" to those ossified authorities, what makes you think
that another forty years of playing nice will accomplish anything?
I am a software engineer and proud of it. I don't want to be called
an "applied mathematician," "digital accountant," "information
specialist," "applied information theorist," "algorithmizer,"
"data organizer and regularizer," "licensed hacker," "data
crunchmeister" or any other imaginative alternative descriptive term
that we have not adopted in forty years.
Parnas and I appear to be after the same things. Professional
recognition, meaningful licensure, and proper standards for our
practitioners. Whilst he continues to apply the methods, which in
my estimation have been tried (by me, among many others) and failed
for over four decades, I will continue to use humor and sarcasm --
to give the licensure establishment the swift kick in the butt which
they richly deserve and which seems to be the only thing that gets
them off the dime.
Boris Beizer
Software Engineer
(But not a licensed professional engineer, in either the US or Canada).
========================================================================
eValid Site Comparisons, WebStore Special, Training
http://www.e-valid.com
Here is a rundown on recent news about eValid.
* Prices Reduced for On-Web Purchases. We know times are pretty
rough -- so we're doing our part! We've lowered the prices of
eValid licenses for WebStore sales! Here's the deal: if you use
our online WebStore to buy one of the standard products or
products bundles you get a 10% price break! Go to:
http://store.yahoo.com/srwebstore/evalid.html
* Keynote's Top 10 Fastest Sites Compared. We completed detailed
WebSite "Online Experience" evaluations of Keynote's Top 10
Fastest Sites -- and they don't all come out looking so great!
See all the details at:
http://www.soft.com/eValid/Promotion/Comparative/Fortune/Fast.Sites/summary.html
* eValid July Training in SF. The next public training session on
eValid is being held 16-18 July 2003 here in San Francisco.
Reservations are now being taken. Bring your sweater; it's likely
to be "cold" here in July! See the complete course description:
http://www.soft.com/eValid/Training/blurb.html
* eValid Ver. 3.2 Support Ending. Support for eValid Ver. 3.2 is
ending 30 June 2003. All eValid users are urged to upgrade to
Ver. 4.0. Please contact us at sales@sr-corp.com for details on how
to arrange an upgrade.
* Download and One-Click Install. Qualify for a free evaluation for
Ver. 4.0 -- including use of the "one click install" process -- by
going to:.
http://www.soft.com/eValid/Products/Download.40/down.evalid.40.phtml?status=FORM
If for some reason the eValid license key robot doesn't give you
the EVAL key you need, please write to us at licenses@e-valid.com
and we will get an eValid evaluation key sent to you ASAP!
========================================================================
Call for Reviewers
Guide to the Software Engineering Body of Knowledge (Trial Version)
The purpose of this review cycle is to gather proposed changes to be
incorporated in the 2003 version of the Guide to Software
Engineering Body of Knowledge (SWEBOK) scheduled for year-end. The
three review cycles leading to the publication of the Trial Version
in May 2001 (version 0.95) were based on expert opinions. Now that
the Trial Version of the Guide has been available for two years and
has been used in varying contexts for different purposes, strong
preference will be given to changes based on trial usage.
The purpose of the Guide is to characterize the contents of the
software engineering discipline, to promote a consistent view of
software engineering worldwide, to clarify the place of, and set the
boundary of, software engineering with respect to other disciplines,
and to provide a foundation for curriculum development and
individual licensing material. All deliverables are available
without any charge at www.swebok.org.
The Trial Version of the SWEBOK Guide was endorsed in 2001 for trial
usage by the Board of Governors of the IEEE Computer Society and is
undergoing the final steps for publication as a Technical Report by
the International Organization for Standardization (ISO TR 19759).
The Guide to the Software Engineering Body of Knowledge (SWEBOK) is
a project of the IEEE Computer Society with corporate support from
Boeing, the Canadian Council of Professional Engineers, Construx
Software, MITRE, the National Institute of Standards and Technology,
the National Research Council of Canada, Rational Software,
Raytheon, and SAP Labs (Canada).
Close to 500 reviewers from over 40 countries participated in the
three review cycles leading to the Trial Version providing roughly
eight thousand comments. Each individual reviewer comment, the
identity of the reviewer who provided the comment and its resolution
are publicly available on www.swebok.org. The next review cycle will
be conducted with a similar approach.
The SWEBOK Guide seeks to identify and describe the subset of
software engineering knowledge that is generally accepted.
Generally accepted knowledge applies to most projects most of the
time, and widespread consensus validates its value and effectiveness
(1). A complementary definition states that generally accepted
knowledge should be included in the study material for a software
engineering licensing examination that graduates would take after
gaining four years of work experience. Although this criterion is
specific to the U.S. style of education and does not necessarily
apply to other countries, it was deemed useful. Research topics and
specialized topics are therefore out of scope.
The Trial Version is organized into 10 chapters dealing with the
following Knowledge Areas: software requirements, software design,
software construction, software testing, software maintenance,
software configuration management, software engineering management,
software engineering process, software engineering tools and
methods, and software quality. The SWEBOK Guide also includes by
reference a list of related disciplines that are important to
software engineers.
Please note that adequate information to implement a recommended
change must be provided by the reviewer for it to be considered.
Well described recommended actions will be given more attention and
credence than vague or imprecise ones. All reviewers will be
recognized by having their name on the list of contributors.
Reviewers will send in their proposed changes via a Web interface.
Detailed review instructions will be sent to all signed-up reviewers
on June 2.
To sign up as a reviewer, please fill in the electronic form
available at www.swebok.org. For further information, please
contact Pierre Bourque (pbourque@ele.etsmtl.ca)
========================================================================
eValid WebSite HealthCheck Offer
<http://www.e-valid.com>
Do you know how healthy your WebSite really is?
Does it have any broken links? Any slow-loading pages?
Are your WebSite pages optimized to provide for the fastest download
performance?
The eValid WebSite test engine provides a very wide variety of tests
and analyses that help you keep your WebSite healthy.
FREE eValid WebSite HealthCheck
We are now offering on a limited basis a FREE eValid WebSite
HealthCheck that includes a sample of key eValid reports:
unavailable links analysis, detailed page timing report, slow-
loading pages report, and detailed SiteMap.
The FREE eValid WebSite HealthCheck gives you an analysis of part of
your WebSite in automatically generated eValid reports that address
such critical quality areas as:
> An Unavailable Links Report using the LinkCheck feature of
eValid's Site Analysis engine. It shows you client-side
availability failures that you can't detect from the server
side.
> A Slow-Loading Pages Report that identifies, among all pages
downloaded, every page that takes longer than 2 seconds to
download (using a fast DSL connection).
> A Detailed Page Download Timing Chart, produced for one of your
WebSite pages, so you can see how to improve the download
response times for that page.
> A Unique Link SiteMap for the all the analyzed pages that
details your WebSite structure and page dependencies.
How To Get Your FREE eValid WebSite HealthCheck
Complete details about the FREE eValid WebSite HealthCheck,
including sample reports and results, are available at:
<http://www.soft.com/eValid/Promotion/HealthCheck/offer.html>.
========================================================================
The 2nd Nordic Conference on Web Services -- NCWS'03
URL: http://www.wscc.ino/ncws/
20 - 21 November 2003
In the last recent years, Web Services have gained a lot of
attention in industry and academia. No surprise that the 1st Nordic
Conference on Web Services in November 2002 (NCWS'02,
http://wscc.info/ncws02/ncws.htm) attracted more than 100 people
from companies and universities in Northern Europe and was
considered a great success. Therefore, we will extend both the focus
and the catchment area of this year's NCWS. Besides the Business and
the Technical tracks, we call for papers and contribution for an
Academic/Research track.
Submissions should introduce novel research results in Web Services
related areas. These areas of interest include but are not limited
to the topics of
Web Services in relation with:
* Traditional Component Systems
* XML
* Semantic Web / Ontologies
* Performance Issues
* Applications / Solutions / Case Studies
* Porting Legacy Applications to Web Services based Applications
* Existing / Emerging / Missing Standards
* Process and Workflow Modeling
* Specification and Discovery
* Design and Composition (including novel composition techniques like AOP)
* Typing and Safety
* Security
Proceedings will be published in the "Mathematical Modelling in
Physics Engineering and Cognitive Science" Series and will be
available at the conference.
========================================================================
========================================================================
------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------
========================================================================
QTN is E-mailed around the middle of each month to over 10,000
subscribers worldwide. To have your event listed in an upcoming
issue E-mail a complete description and full details of your Call
for Papers or Call for Participation to .
QTN's submittal policy is:
o Submission deadlines indicated in "Calls for Papers" should
provide at least a 1-month lead time from the QTN issue date. For
example, submission deadlines for "Calls for Papers" in the March
issue of QTN On-Line should be for April and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
(about four pages). Longer articles are OK but may be serialized.
o Length of submitted calendar items should not exceed 60 lines.
o Publication of submitted items is determined by Software Research,
Inc., and may be edited for style and content as necessary.
DISCLAIMER: Articles and items appearing in QTN represent the
opinions of their authors or submitters; QTN disclaims any
responsibility for their content.
TRADEMARKS: eValid, SiteWalker, TestWorks, STW, STW/Regression,
STW/Coverage, STW/Advisor, TCAT, and the SR, eValid, and TestWorks
logo are trademarks or registered trademarks of Software Research,
Inc. All other systems are either trademarks or registered
trademarks of their respective companies.
========================================================================
-------->>> QTN SUBSCRIPTION INFORMATION <<<--------
========================================================================
To SUBSCRIBE to QTN, to UNSUBSCRIBE a current subscription, to
CHANGE an address (an UNSUBSCRIBE and a SUBSCRIBE combined) please
use the convenient Subscribe/Unsubscribe facility at:
<http://www.soft.com/News/QTN-Online/subscribe.html>.
As a backup you may send Email direct to as follows:
TO SUBSCRIBE: Include this phrase in the body of your message:
subscribe
TO UNSUBSCRIBE: Include this phrase in the body of your message:
unsubscribe
Please, when using either method to subscribe or unsubscribe, type
the exactly and completely. Requests to unsubscribe
that do not match an email address on the subscriber list are
ignored.
QUALITY TECHNIQUES NEWSLETTER
Software Research, Inc.
1663 Mission Street, Suite 400
San Francisco, CA 94103 USA
Phone: +1 (415) 861-2800
Toll Free: +1 (800) 942-SOFT (USA Only)
FAX: +1 (415) 861-9801
Email: info@sr-corp.com
Web: <http://www.soft.com/News/QTN-Online>