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@sr-corp.com Web: <http://www.soft.com/News/QTN-Online>