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 =======+
+======= July 2003 =======+
+===================================================+
QUALITY TECHNIQUES NEWSLETTER (QTN) is E-mailed monthly to
subscribers worldwide to support the Software Research, Inc. (SR),
eValid, and TestWorks user communities and to 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 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 eValid Bay Area Training Session Available
o Reply to Beizer's Article by Merlin Dorfman
o International Symposium on Modern Computing (honoring the
100th birthday of John V. Atanasoff)
o "Practical Software Testing," by Ilene Burnstein
o Special Issue Announcement: Current Practice of Return On
Investment (ROI)
o Great Summer Deal on eValid Server Loading Bundle
o Workshop on Formal Aspects in Security and Trust (FAST)
o Foundations of Software Engineering (FSE-11)
o eValid Performance Enhancements in New eValid Builds
o Special Issue of Software Process Improvement and Practice
o QTN Article Submittal, Subscription Information
========================================================================
eValid Bay Area Training Session Available
We are pleased to be able to offer 1-day, 2-day, and 3-day eValid
training courses. The next eValid training sequence at which seats
are available is scheduled for:
Wednesday, 27 August 2003
Thursday, 28 August 2003
Friday, 29 August 2003
------- -----------------------------------------------------------
Day Single-Day Course Description
------- -----------------------------------------------------------
1 WebSite Mapping and QA. Prepares you for detailed QA
analysis of websites using the eValid side analyzer.
2 Testing and Tuning. Complete coverage of the functional
testing and detailed tuning aspects of eValid, including
regression testing and test suite management.
3 Performance Testing. Complete coverage of use of eValid
LoadTest methods that can infer server capacity in terms of
number of users within performance ranges and associated
client-side loading issues.
------- -----------------------------------------------------------
Days Combination Day Course Description
------- -----------------------------------------------------------
1+2 WebSite Behavior. Applies eValid to general investigations
of how well your website appears to users, it terms of
structure, timing/performance, quality.
2+3 WebSite Performance. Combined server capacity and response
time checking and individual page performance.
1+2+3 WebSite Quality. The full spectrum of WebSite Quality
issues, including mapping, functional testing,
timing/tuning, loading and monitoring.
------- -----------------------------------------------------------
A complete description of the eValid training curriculum that
includes complete contents for each of the three one-day modules can
be seen at:
<http://www.soft.com/eValid/Training/curriculum.html>
-------------- -------------------
Description Registration Fee*
-------------- -------------------
1-Day $495/person
2-Days $695/person
3-Days $895/person
-------------- -------------------
Space is limited to a total of 8 students at one time to assure the
best possible student-instructor interaction. All course handouts,
access to the eValid engine with high speed DSL support, plus a
daily light lunch and refreshments are all included in the
Registration Fee
*Note: Training vouchers you received with your eValid purchase or
lease agreement can be used for this event.
Classes are conducted at the eValid offices in San Francisco,
California. The facility is centrally located, close to public
parking, and easily reachable by public transit.
Contact us immediately to reserve your place at this event! Space
is limited. Send email to .
========================================================================
Reply to Beizer's Article
by
Merlin Dorfman, PhD, PE
> 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?
70% is also the typical passing grade for licensing exams for
doctors, lawyers, dentists, veterinarians, etc. Does Dr. Beizer treat
his own illnesses and write his own contracts rather than deal with
doctors and lawyers who may have only gotten 70% on licensing exams?
Or does he recognize that a license is a statement of _minimum_
qualifications and look for additional qualifications such as
specialization, additional experience, or additional education
before selecting a provider?
Basically if you have to work many problems in a few hours,
you will not get all of every problem right. Professional work
allows more time and allows for review by others. The examination
model is not a good representation of how we work in practice so an
expectation of 100% on an exam is not valid.
And which of us got 100% on all our exams in college? We all
got through on part credits, yet we got our degrees and succeed in
professional life.
> 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?
That's one of the reasons we have peer reviews...because we are
not expected to get it right, working alone, the first time we sit down.
It's also one of the reasons we do testing.
> 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.
I'm not at all sure that electronics is excluded. Or computers,
for that matter. It probably depends on which exam. Probably the
Civil Engineering exam doesn't have much on electronics. But then
the Industrial Engineering exam doesn't have much on thermodynamics,
either. The Fundamentals exam is just what the name says--circuit
theory and thermodynamics are more "fundamental" than electronics
and software. But fundamentals also do not include specific
application areas in other specialties either.
> 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.
This may partially explain the 70% pass criterion. It's unlikely
that all the questions a candidate answers on the exam are completely
within a the knowledge of the candidate; some are partially in those
many areas where the candidate has only this technological layman's
knowledge. So the candidate will get less than full credit on these
questions.
> 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?
Most don't keep up nearly as well as Dr. Beizer does. Should
they be disqualified from practicing?
> 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.
Bad idea! Employers should want a broadly educated employee,
not one who has specific skills in the latest hot-button technology
that will be obsolete in five or ten years. (An employee with a PE
presumably has the broad background.)
> 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.
I don't believe the "Renaissance Man" analogy is accurate. That's
why candidates only have to answer a fraction of the questions on the
exam. And they are not expected to score 100% even on those questions.
> 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.
"All professions are a conspiracy against mankind"--Charles
McCabe.
There may be something to this for civil/construction
engineering; I just don't know. But certainly not elsewhere, as
shown by the small percentage of practitioners who are PEs.
> How has the "Professional Engineering" oligarchy
> maintained the myth? By simply saying that anything that doesn't 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'm not clear how this relates to the topic...
> 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.
Or not. One of the problems is that "engineering software" is
written by people with training in the application domain (fluid
dynamics, structural analysis, etc.), but not in software engineering
--physicists, mathematicians, engineers of all other kinds. And
guess what--the software is chock full of defects, is hard to use and
unmaintainable...all those symptoms of poor software engineering!
> 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.
Indeed, much of the "engineering software" exhibits very little
"software engineering."
> 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.
The big problem here is that the vendors are not liable for
defective software that they sell. If they were held liable, you
can bet they would be a lot more careful about what they put on
the market. But don't get me started on that topic...
Dr. Beizer has identified a definite problem here, but the PE
doesn't solve it. A PE license is required to offer services to
the public. Employers are (or should be) qualified to evaluate the
qualifications of prospective employees. They may use a PE as one
of the criteria, or they may prefer to use a certification like the
IEEE CSDP, which is focused specifically on the body of knowledge
required for software development--no thermodynamics! When vendors
are held responsible for the quality of the software they put on
the market, you can bet they will look more closely at the
qualifications of their employees, the tools and processes used,
etc.
> 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."
No, the PE is for people who offer services to the public, so
their customers/clients can tell who is (minimally) qualified and
who is not. Very few software engineers offer services to the
public.
If software engineers are having problems advertising their
services to industrial employers--who, unlike "the public," should
be able to evaluate candidates' qualifications--then we need to get
involved in changing the rules. Not necessarily the rules for PE
registration, but the rules for advertising.
> 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.
Are you sure about this? I know that non-PEs may have their
qualifications challenged...may need to establish their qualifications
> 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.
This is an important point. If you want to advertise your
services to the "man in the street," as a civil engineer might
advertise to somebody who wants to design a structure for his
farm or factory, you must be a PE. Software engineers typically
want to be employed by, or to be under contract as consultants to,
firms that are qualified to evaluate the applicant's credentials.
A PE should not be required in this case. An employer may ask for
it, but the law should not require it. If there are cases where a
software engineer has been prohibited from this kind of advertising,
we need to get the laws, regulations, or interpretations changed.
And the PE "establishment" should agree--after all, software isn't
"real engineering," is it? :-)
> 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.
If this is true, it should be challengeable. It is also
unethical for a PE to sign off on something he/she does not
understand. A software-ignorant PE is committing an ethical
violation to sign off on a project with significant software content.
But Dr. Beizer has identified an area where software engineers
have some leverage. If custom software is being developed as part
of a civil or mechanical engineering project--as part of the
deliverable product--we need to raise a stink about the possible
consequences to safety, cost, schedule, and performance if the
software is developed by unqualified individuals. But we need to
have a proposal for how competence should be determined. If we
want it to be a Software Engineering PE, we need to have a fully
developed proposal. Or we might use something like the CSDP.
> 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.
If this happens--file a violation against the PE who signed
off, and make sure that verifiably qualified software engineers are
available.
> 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.
If software-ignorant PEs are signing off on these things, we
should challenge their competence (and their ethics). The Denver
Airport baggage system specifically was a problem of software management
or of software system engineering; we can't blame that one on
unprofessional software engineers. The decisions that led to the
problems were made by managers who didn't need to be, and probably
weren't, PEs anyway. By the time software engineers got to work, the
project was already doomed. (See W. Wayt Gibbs's article in the
September 1994 "Scientific American.") In fact, most software problems
can be traced to bad management, not bad engineering!
> 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.
For the most part, the proper course is to get software engineers
certified as CSDPs or something similar, since we do not offer our
services to the public. And to hold vendors liable for defects in the
software they sell.
For some specific cases, Dr. Beizer has identified situations
where the public stands to suffer significant harm through the present
system. We need to raise red flags about those situations. He's also
raised the issue of possibly being unable to advertise consulting
services to employers who are qualified to judge an applicant's
credentials. If this is the case, we need to work on remedying it.
> 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.
How can foreign suppliers with American customers avoid the
US 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.
Excellent idea!
> d. Ask why you can't get a license to practice your profession.
Because you don't offer your services to the public, hence a
license is not necessary. If you offer your services to industrial
customers, your right to do so without a PE should be recognized.
> 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.
Good luck! I doubt if Bill would do anything to make his
software engineers more recognizable and employable elsewhere, or
to make their qualifications more visible so he would have to pay
them more.
> 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.
Dr. Beizer and I have discussed this before, but any engineering
graduate should be able to pass the Fundamentals exam. EEs,
including Electronics, should have the basics of physics, chemistry,
thermodynamics, etc. I don't believe a person can get an electronics
degree without taking these courses. The degree would not be
accredited otherwise. After all, the Fundamentals exam is very
closely tuned to the requirements for accreditation.
> 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.
ABET now has accreditation criteria for Software Engineering,
although as best I can determine there are no accredited programs.
Like all accredited engineering programs, software requires mathematics,
basic sciences (including experimental science), engineering sciences,
and engineering design "appropriate to the discipline." When you ask
for your alma mater to develop an accredited software engineering
program, be sure you understand and accept the corollaries.
<http://www.abet.org/images/Criteria/E1%2003-04%20EAC%20Criteria%2011-15-02.pdf>,
page 20 (page 16 if you don't count the Roman numeral pages). This is
in addition to the general criteria on pages 1-3 (5-7 if you don't
count the Roman-numeral pages).
> 8. Let the politicians, the lawyers, the hard-hat engineers, all
> know that:
>
> YOU ARE A SOFTWARE ENGINEER!!!
I also wanted to respond to a few of Dr. Beizer's rebuttal points
to Prof. Parnas:
----------------------------------------
> 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
I believe Dr. Parnas was referring to accredited degree programs
in universities, rather than to professional licensing. As mentioned
above, it is now possible to accredit a Software Engineering degree
program under ABET criteria, but I am not aware of any that have
actually done so in the US.
> 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?
I expect that Dr. Parnas's registration is as something other
than a Software Engineer. However a process for registering software
engineers in Ontario is (or was at last notice) working its way through
the system. (In Canada, professional registration--designated "P.Eng."
--is primarily under the control of the engineering societies rather
than the government.)
> 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?
Maybe it means that the discipline is changing so fast that we
can't identify the body of knowledge or evaluate qualifications yet.
(A moving target.)
> 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:
Let me re-emphasize that certification and licensure are not the
same thing. One is a recognition among the profession and the other
is a legal authority to carry out certain activities. One is much
easier than the other to put in place!
> 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.
It's hard to say what actually causes change, but I believe it
is more realistic to credit the progress to those software
professionals who quietly worked through CSAB, ABET, IEEE,
universities, and other organizations to influence those in a
position to cause changes. Dr. Beizer makes a persuasive case that
we need to be more active politically, e.g., through the state
legislatures. This is a different issue from _how_ we communicate:
through quiet reason or through sarcasm.
> 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.
This is a point that needs to be made more often. Engineering
represents a way of thinking, an attitude of problem-solving, that
does not necessarily come from a degree program in computer science,
information technology, or other related disciplines. Whether or
not one studies thermodynamics, chemistry, or other subjects that
are part of traditional engineering programs, this attitude and
philosophy is an essential part of being an engineer. It needs to
be included in accredited software engineering degree programs. It
also needs to be part of the qualifications for any licensure in
software engineering, and a good case can be made that it should be
part of any non-licensing certification. Let's make sure that
registered or certified software engineers have engineering skills
in addition to software skills.
========================================================================
"Practical Software Testing," by Ilene Burnstein Available
"Practical Software Testing," by Ilene Burnstein takes a unique
approach to teaching readers how to effectively plan for testing,
design test cases, test at multiple levels, organize a testing team,
and optimize use of testing tools. It introduces testing concepts
that are managerial-, technical-, and process-oriented, using the
Testing Maturity Model (TMM) as a framework. For more information,
please visit <http://www.springer-ny.com/detail.tpl?isbn=0387951318>
With its accessible, practical, and well-focused framework, this new
resource provides an integrated presentation of software testing
processes and practices. Professionals and practitioners in
software testing, software quality assurance, or software validation
and verification will benefit greatly from using this essential
resource.
The book includes a sample test plan, comprehensive exercises, and
definitions for software testing and quality. It also covers
testing topics with either procedurally based or object-oriented
programming code.
========================================================================
The International Symposium on Modern Computing
In Celebration on John Vincent Atanasoff's 100th Birthday.
October 30 - November 1, 2003 at Iowa State University, Ames, Iowa
What motivated professor John Vincent Atanasoff to invent a machine
whose basic principles would change the face of technology forever?
It was neither fame nor fortune, but rather his desire to find a
better, more efficient way for his students at Iowa State University
to learn. Specifically, he was seeking a way to help his graduate
students spend less time working on lengthy linear equations by hand
or mechanical means. As a result, from 1939 through 1942, the
Atanasoff-Berry Computer became a reality in the basement of the
Physics Building on the Iowa State University campus in Ames, Iowa.
As a national tribute to this pioneer whose accomplishments have
been recognized internationally, Iowa State University is organizing
an International Symposium on Modern Computing to celebrate
Atanasoff's 100th birthday. We are inviting leaders in the computing
field to join us and to speak and lead workshops on the newest
technologies and research that have the potential to again change
the world dramatically.
Industry leaders, government representatives, college and university
students, faculty and researchers from across the nation are invited
to participate in this unique three-day symposium. The symposium
will feature Dr. Gordon Bell, senior researcher, Microsoft Corp. and
Dr. Doug Van Houweling, CEO, University Corporation for Advanced
Internet Development, plus an array of experts in computation
intelligence, application specific IT infrastructures, high-
performance computing and Grid computing.
For more information: www.iastate.edu/JVA-2003 or contact symposium
general chairs S.S. Venkata (venkata@iastate.edu) or Carl Chang
(chang@iastate.edu).
========================================================================
Special Issue Announcement:
Current Practice of Return on Investment (ROI)
IEEE Software is soliciting contributions for a special issue on the
current practice of Return on Investment (ROI) analysis in the
software industry. The special issue will focus on the impact of
process-related, managerial and technical choices as well as new and
ongoing software capital initiatives from an ROI perspective. Types
of contributions that are within scope include:
* ROI analysis for improvement of existing or adoption of new
software development processes and methods; * ROI analysis of
acquisition versus in-house development of software; * ROI analysis
of software infrastructure and platform investments, including
restructuring and migration projects.
ROI in this context refers to the realized or anticipated net
benefits of an activity, possibly adjusted for risk. Of the three
main ROI components - cost, benefit and risk - contributions should
preferably address all three. Contributions may take a snapshot of
current practice or propose techniques that have potential to
improve the current practice. They should be accessible to
practicing software engineers, yet deliver persuasive arguments for
executives. Articles on practical approaches that are not well known
in the software industry, but are being successfully applied in
other industries are encouraged.
Contributions are solicited in the following categories:
* State-of-practice articles: How do software organizations define
and use ROI for process-related, product-related, managerial and
technical decisions? How do software organizations forecast ROI
for new initiatives?
* Case studies that clearly illustrate the value and use of
practical ROI concepts and persuasively go beyond "it worked
well for us."
* Emerging practical approaches for analyzing ROI in a software
organization.
* Assessment of intangible benefits and disciplined qualitative
measurement techniques.
Complex theoretical treatments of ROI and approaches with little
immediate practical application are outside the scope of the special
issue.
Guest Editors
* Hakan Erdogmus
* John Favaro
* Wolfgang Strigel
For submission instructions and further information, visit:
<http://seg.iit.nrc.ca/yawc/roi/wiki.cgi>
========================================================================
Great Summer Deal on eValid Server Loading Bundle
Get your server load testing work done quickly and accurately with
the most realistic server loading capability ever created -- test
sessions with multiple eValid full-browser playbacks. For a limited
time only you can have a complete eValid Server Loading Bundle on a
special 90-day license -- project oriented and budget protecting --
only $2,995. That's 50% off the full price! This special pricing
will give you faster time to value and the opportunity to dig into
the deep pockets of eValid's benefits.
Advantages
eValid features full browsers so there are no virtual users! You can
have total confidence that the load you impose on your servers
really is what your users impose. There's no fooling around with
simulations and approximations with eValid.
What's more, included in the short-term license you also get a 7-day
eValid infinite user key. Test scenarios you develop on your main
driver machine can be spread across every machine in your enterprise
using a special 7-day key. You can run loading experiments that
involve an unlimited number of simultaneous playbacks!
Features
The eValid Server Loading Bundle includes all of this:
o Full professional level record play capability. Your functional
tests can be as deep and complex as you like.
o Full data-driven test support. LoadTest capability with real
time monitor and result charts.
o Thin playback-only browser to minimize RAM requirement.
o Unlimited users on your test machine.
o Short term infinite user license -- good for 7 days, you can run
your load test scenario on as many machines as you like.
o Purchase with a credit card and we'll include a second 7-day
infinite user license at no extra cost.
Offer Details
Offer expires 15 August 2003. New customers only. Credit card
(MasterCard/Visa) transaction required for extra 7-day infinite user
key. Infinite use keys may be used any time within the 90-day
license period. Additional restrictions may apply. Contact
to place your order.
========================================================================
Workshop on Formal Aspects in Security & Trust (FAST)
Pisa, Italy, 8 September 2003
http://www.iit.cnr.it/FAST2003
FAST is a satellite event of the 12th Formal Methods Europe
Symposium (FME)
OVERVIEW The first international Workshop on Formal Aspects in
Security & Trust (FAST) wishes to contribute to the aggregation of
researchers in the areas of security and trust. The new challenges
offered by the so-called ambient intelligence space as a future
paradigm in the information society demands for a coherent framework
of concepts, tools and methodologies to enable user' trust &
confidence on the underlying communication infrastructure. These
need to address issues relating to both guaranteeing security of the
infrastructure and the perception of the infrastructure being
secure. In addition, user confidence on what is happening must be
enhanced by developing trust models effective but also easily
comprehensible and manageable by users.
The complexity and scale of deployment of emerging ICT systems based
on web service and grid computing concepts also necessitates the
investigation of new, scalable and more flexible foundational models
of enforcing pervasive security across organizational borders and in
situations where there is high uncertainty about the identity and
trustworthiness of the participating networked entities (including
users, services and resources). The increasing need of building
activities sharing different resources managed with different
policies demand for new and business enabling models of trust
between members of virtual communities including virtual
organizations that span across the boundaries of physical
enterprises and loosely structured communities of individuals.
Original papers on formal aspects of security and trust are very
welcome. Suggested submission topics include, but are not limited
to:
- Security and trust policy models
- Security protocol design and analysis
- Formal models of trust and reputation
- Logics for security and trust
- Distributed trust management systems
- Trust-based reasoning
- Digital assets protection
- Data protection
- Privacy and ID issues
- Information flow analysis
- Language-based security
- Security and trust aspects in ubiquitous computing
- Validation/analysis tools
- Web service security/trust/privacy
- Grid security
- Security risk assessment
- Case studies
WORKSHOP ORGANIZERs
Theo Dimitrakos (T.Dimitrakos@rl.ac.uk), BITD-CCLRC
Fabio Martinelli (Fabio.Martinelli@iit.cnr.it), IIT-CNR
========================================================================
11th ACM SIGSOFT International Symposium on the
Foundations of Software Engineering (FSE-11)
1 - 5 September 2003
Helsinki, Finland
The Advance Program of the ESEC/FSE 2003 conference is now available
on-line at the conference web site:
http://esecfse.cs.Helsinki.fi
Welcome to the European Software Engineering Conference and
ACM SIGSOFT Symposium on the Foundations of Software Engineering
(ESEC/FSE 2003)!
Since 1980's, the European Software Conference has been the meeting
place of the European software engineering research community. Since
1997 the conference has been organized every two years together with
ACM SIGSOFT's Symposium on the Foundations of Software Engineering,
making the event truly international.
In September it is time to meet again, this time in Helsinki, the
capital of Finland. ESEC/FSE 2003 will bring together researchers
and practitioners of software engineering to report new innovative
research results and to exchange experiences related to both
traditional and emerging areas in software development.
The conference contains: ,nf - invited talks by Lee Osterweil,
Giuseppe Longo, and Ari Jaaksi, - 33 full papers and 9 short papers,
- 5 tutorials, - 3 workshops and 2 co-located workshops.
As the general chair of the conference I highly encourage you to
browse through the technical program and the list of speakers,
tutorials, workshops and co-located events and see why you really
should attend ESEC/FSE this year.
Contact: Jukka Paakki
General Chair of the ESEC/FSE 2003
========================================================================
Performance Enhancements in New eValid Build
The latest builds of eValid include several major performance
enhancements. This build will be particularly valuable if you are
running large site analyses or if you are running large LoadTest
scenarios.
o Footprint. The new build manages memory in a different way and
the result is a smaller initial footprint and slower growth in
footprint size as browsing continues.
o Performance. Several working areas within eValid have had
significant speedups so you will see lower total CPU utilization
throughout the run.
o Capacity. The overall capacity of the eValid browser,
particularly when doing large site analyses, should see a
significant gain over prior versions.
Obtaining The New Version
Use the instructions that were sent by email with your evaluation or
revenue key to re-download from our website. If you have
difficulty, or if you did not save your key distribution email,
please contact and we'll resend the
instructions.
========================================================================
Special Issue of Software Process Improvement and Practice
<http://www.interscience.wiley.com/jpages/1077-4866>
Bridging the Process and Practice Gaps Between
Software Engineering and Human Computer Interaction
Special Issue Editors
Rick Kazman (kazman@sei.cmu.edu)
Len Bass (ljb@sei.cmu.edu)
Usability is an important quality attribute for many computer
systems. Everyone involved in the development and use of
interactive systems agree on this. Yet we continue to see
interactive systems that are less usable than they should be. This
is partially the result of gaps between software engineers and human
computer interaction engineers.
The causes for the gaps are multiple but they include: a mismatch
between the usability life cycle and software engineering life
cycles; a lack of tools, notations, and methods for infusing
usability concerns into portions of the software engineering life
cycle; different names for essentially identical techniques; and the
cost of building interfaces designed by human computer interaction
engineers.
Cost affects the as-built interface both because of the cost of
iteration (an essential element of interface design) and because the
as-designed interface may make technological assumptions about how
easy certain features are to implement. For example, making tabs in
a tabbed display a specialized shape, as proposed by the interface
designers, might add two weeks to the development schedule.
Technical issues affect the as-built interface because the changes
suggested during the iterative design process may be difficult to
implement since the software engineers did not provide system
facilities to support proposed changes. For example, an appliance
might be placed into an unusable state with a particular combination
of button presses. Fixing the problem might involve a major re-
design of the software.
The purpose of this special issue is to identify root causes of the
gaps between software engineering and human computer interaction and
to identify solutions to these gaps. We are soliciting papers that
identify one or more root causes and describe validated solutions.
Topics of interest include:
o Software architectures and architecture analysis for interactive
systems
o Joint development processes
o Methods, tools, and notations that address both software
engineering and HCI concerns
o Portability, consistency, and integrability with respect to the
user interface
o Case studies of joint software engineering and HCI design
========================================================================
------------>>> 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, HealthCheck, eValidation, 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@soft.com
Web: <http://www.soft.com/News/QTN-Online>