Forum for Academic Software Engineering Volume 4, Number 12, Fri May 27 10:28:06 CDT 1994 Topics: April Fool Re: Who owns the software? (3 articles) IEEE Software - Editor-in-Chief search - deadline approaching Faculty position--Griffith University Faculty Position in the Technion Ph.D Study in Software Engineering from comp.parallel CFP: 8th CSEE CFP: Symp. Quality Software Engineering Standards and Industry A------------------------------------------------------- From: Keith Pierce Subject: April Fool The article "Clinton Kills Software Engineering", appearing on or about April first, provoked interesting reactions. Several of you replied in an obvious state of panic. At least one military professor called the Pentagon. And at least one subscriber fired off angry messages to the White House's real email address. I posted the same message on several internet newsgroups, and it's still generating followup messages. Apparently I struck a nerve: perhaps we suffer from an inferiority complex similar to computer science faculty who in the 60's and 70's struggled to persuade their colleagues of the legitimacy of computer science as an academic field. I'm thinking of composing an article based on this phenomenon, and I'd like to hear more anecdotes about the message and reactions to it. Please mail me at the above address. Keith Pierce A------------------------------------------------------- From: Dale Shaffer Subject: Re: Who owns the software? In response to David Hecker's question (Vol 4, Number 11) about ownership of software when produced as part of a class, I addressed the same problem a few years ago here at Lander University. The solution was to assign all proceeds to a student computer science scholarship fund. The administration, myself, and the involved students were all happy with the solution. Dale Shaffer Lander University Greenwood, SC DShaffr@Clemson.Clemson.Edu A------------------------------------------------------- From: Mary_Shaw@cs.cmu.edu Subject: Re: Who owns the software? Here's another possibility -- Agree that if the software ever yields a profit, the profit will go to a special account whose purpose is to support the program (whatever program most of the students are in) in some special way. I know, for example, of books with many contributors where everyone has agreed to put the royalties in such a pool. The reasoning is that splitting modest income among a lot (20-30) people yields nothing that really makes any difference to them, but pooling the proceeds can support, for example, one special lecture a year at whatever school was home base for the book. Mary Shaw Carnegie Mellon University mary.shaw@cs.cmu.edu A------------------------------------------------------- From: Jose Luis Braga Subject: Re: Who owns the software? Keith: I have been involved with the same problem related in the message "Who owns the software?", from D. Hecker. I also teach Software Engineering, and in general I try to propose projects to my students that can become useful and usable software. And the best way I found to disseminate software produced this way is letting it be "public domain". Our software is always presented by a first screen, containing a notice on authorship, addresses, the name of the developers, and so on. No idea of final product is involved, and so the idea of making money with the software is also not involved. The students more closely involved with the project have the opportunity to acquire knowledge to make another system even better than the one that is being released, when they finish their courses. ze luis. **********************************+******************************* |Jose Luis Braga |Tel.:+ 55(031)8992394/8992398 | |Departamento de Informatica |E-mail:zeluis@brufv.bitnet | |Universidade Federal de Vicosa |Telex:+ 55(031)1587 | |36570-000 Vicosa - Minas Gerais|Fax:+55(031)8992290 | | B R A S I L | +55(031)8911903 | **********************************+******************************* A------------------------------------------------------- From: Elliot Chikofsky Subject: IEEE Software - Editor-in-Chief search - deadline approaching IEEE SOFTWARE APPLICANTS SOUGHT FOR EDITOR-IN-CHIEF - IEEE SOFTWARE MAGAZINE ** Materials due: May 31, 1994 ** The IEEE Computer Society is seeking applicants for the position of Editor-in-Chief (EIC) of IEEE SOFTWARE magazine for the publication years 1995 and 1996. The EIC is a two-year appointment by the President of the Computer Society. As with many Computer Society appointments, an individual may only serve two consecutive terms, in this case a four year maximum. 1994 is Carl Chang's fourth and final year as Software's EIC. His predecessors were Bruce Shriver (founding EIC) and Ted Lewis. Applicants should have recognized expertise in the software community and significant editorial experience, and be able to lead active editorial (EB) and industry advisory (IAB) boards and to work effectively with technical and publishing professionals. Applicants must have clear employer support for this activity. Each prospective candidate is asked to provide a complete resume, a letter of support from the candidate's employer, and a position statement describing the candidate's assessment of IEEE Software, vision for the future, and specific proposed changes or suggestions for improvement. Full materials are due May 31. The search committee expects to bring its recommendation forward by June 14. Interested individuals should promptly contact the search committee chair, Ann Miller of Motorola Satellite Communications, at 602-732-3874; fax 602-732-3837; email Ann_Miller-P25430@email.mot.com. Ann Miller Motorola Satellite Communications Maildrop: AZ 10 G1137 2501 South Price Road Chandler, AZ 85248-2899 USA Applications may be submitted electronically or via hardcopy. If you send hardcopy near the deadline, please use some form of express mail. You can send a group mailing to the entire committee (e-mail addresses follow) or you can mail your application package to Ann Miller who will forward it to the committee. The search committee consists of: Ann Miller of Motorola (IAB) Ann_Miller-P25430@email.mot.com Angela Burgess (IEEE Software Managing Editor) a.burgess@computer.org Carl Chang of Univ. Illinois Chicago (current EIC) ckchang@eecs.uic.edu Elliot Chikofsky of DMR Group (TCSE Chair) e.chikofsky@computer.org Barry Johnson of U Virginia (VP for Pubs, ex officio) bwj@virginia.edu Tomoo Matsubara of SRA (IAB) matsu@sran125.sra.co.jp The following documentation required from each applicant: (i) Position Paper -- this is a one page (or so) paper describing your assessment of IEEE SOFTWARE and your vision for the future; specific proposed changes and suggestions for improvement should be provided; (ii) Complete Resume, delineating general background/qualifications; (iii) Letter of Support from employer -- the position of EIC is a time-consuming effort, requiring commitment not only of the Editor but also the Editor's employer. Reply to: Ann_Miller-P25430@email.mot.com A------------------------------------------------------- From: Terry Rout Subject: SE faculty position--Griffith University GRIFFITH UNIVERSITY Faculty of Science and Technology School of Computing and Information Technology Lecturer Software Engineering (Ref. No. A5-94) The School of Computing and Information Technology at Griffith University wishes to appoint a Lecturer to support research and undergraduate and postgraduate teaching in the area of Software Engineering. Applicants should possess a suitable higher degree, an established research record, and teaching experience. The multi-disciplinary School is one of the largest Schools of Computing or Information Technology in Australia, with twenty-eight academic staff including three Professors and four Associate Professors, together with support staff and extensive computing facilities. The main undergraduate course offered by the School is the Bachelor of Information Technology, which has majors in computing science, software engineering, information systems, and artificial intelligence. The School also offers Honours, MPhil, and PhD degrees, and a Graduate Diploma in Software Quality. New undergraduate and postgraduate degrees are being planned. Research strengths in the School include parallel and high performance computing, imaging and visualisation, database systems, software engineering, information systems, and artificial intelligence. The School hosts the Australian Software Quality Research Institute, which serves as a focus for research in software quality and software engineering. Its primary concern is the development of technology for software product and process evaluation, measurement, improvement and standardisation. It collaborates with international and national research, government, private, and standards organizations. The appointee will be expected to contribute to its active research program. The appointee will be expected to contribute to teaching at undegraduate, Honours, and postgraduate levels, and to pursue an active research program in collaboration with other members of the SQI. The position is tenurable and is available immediately. The salary range is A$41,574 to $49,370. Applications must clearly state the position being applied for, include a curriculum vitae with the names and addresses of at least three referees, and be addressed to Mr James Walden, Faculty Manager, Faculty of Science and Technology, Griffith University, Queensland 4111, Australia. Enquiries should be addressed either to Professor Rodney Topor, Head of School, on phone +61 7 875 5042 or fax +61 7 875 5051 or email rwt@cit.gu.edu.au, or to Professor Geoff Dromey, Director of the SQI, phone +61 7 875 5002 or email rgd@cit.gu.edu.au. Applications close on 30 June 1994. The position is located on the Nathan Campus, 10km from the centre of Brisbane, a city of over one million people, with a subtropical climate and excellent social, recreational and cultural facilities. A------------------------------------------------------- From: Opher Etzion Subject: Position in the Technion FACULTY POSITION at THE TECHNION- Israel Institute of Technology In the Software Engineering Area ----------------------------------------------------------------- Applications are invited for a tenure track faculty position in the Information Systems Engineering group. The group is part of the Faculty of Industrial Engineering and Management, a large inter-disciplinary school within the Technion - the leading technological institute of Israel. The applicant must have (or is about to receive) a Ph.D. degree, be familiar with information systems and technologies and engaged in active research. Software engineering is of particular interest. The Information Systems Engineering group consists of a number of young Faculty members. The successful candidate will have the opportunity to participate in developing educational programs at both the undergraduate and graduate levels. The focus of the group is on collaborative research combining various information technologies to create an infrastructure for advanced application of information systems. Applications including resume and at least three references (please indicate E-mail addresses) should be sent to: Professor U. Rothblum Dean, Faculty of Industrial Engineering and Management Technion, Israel Institute of Technology Haifa 32000, Israel. A------------------------------------------------------- From: kung@cse.uta.edu (David Chenho Kung) Subject: Ph.D Study in Software Engineering Graduate Studies and Research in Software Engineering Center for Telecommunications (SECT) Please email to: se_phd@homer.uta.edu SECT is a component of Department of Computer Science Engineering, the University of Texas at Arlington. It was established in 1988 to promote faculty and graduate student research in the formulation and investigation of state-of-the-art software engineering technology. Through the intensive research and the transfer of the research results, the center serves both the students in the academic community and the users (sponsors) in business and industry community. The center especially places emphasis on carrying fundamental or innovative ideas in software engineering to the real-world application, and the process goes through a series of stages of conceptualization, exploration, realization and dissemination. The research in SECT has been funded by private sectors in industry as well as state and federal government agencies, including Fujitsu, HP, IBM, NEC, and Texas Advanced Technology Program. Research Facilities ------------------- Excellent facilities are available to support the research in SECT. They range from Cray-XMP, Sequent Symmetry System, VAX 8800, IBM 4341 and 4381, to numerous Sun workstations, HP workstations, Micro VAXs, and personal computers such as IBM PC/PS and Macintosh. Current Research Topics ----------------------- The research topics in SECT include development of object-oriented software, software requirement engineering, construction of PBX software system, safety analysis in critical software system, real-time software system testing, CASE, and concurrent engineering in software development. Some of the ongoing projects are as follows. * Object-Oriented Testing and Maintenance * Requirement Analysis in Software Engineering * Distributed Real-time Embedded Systems Testing * Software Process Modeling and Improvement * Formal Specification and Rapid Prototyping * Incremental Delivery of Software Systems Financial Aid ------------- Graduate assistantships and fellowships are available for qualified candidates. Financial aid recipients are also entitled to the in-state tuition rate of the University of Texas System. Tuition and Fees ---------------- The in-state tuition (resident) is the greater of $100 minimum or $28 per semester credit hour. Non-Texas resident tuition is $171 per semester credit hour. Location -------- UTA is located in the ourskirts of Dallas, Texas. The metropolitan area offers a variety of cultural and recreational opportunities including art, history, science museums, opera, symphony, ballet, theater, zoos, parks, lakes, and professional sports. The area supports many national and international industries. Employment opportunities in computer-related fields are excellent. The temperature range from 15 to 100 degrees F. with a yearly average of 70 degrees F. Admission Requirement --------------------- We prefer PhD students who have: (1) a master's degree in computer science or a related field, preferably with thesis. (2) a 3.5 GPA (on a 4.0 scale) or higher in all previous work. (3) a sum of verbal and quantitative scores of 1250 or higher on GRE. (4) strong recommendations. (5) a statement of goals indicating an area of research which can be supported by the faculty. The Software Engineering Center for Telecommunications (SECT) invites all qualified PhD candidates in computer science to apply. Applicants can fill in the following form or contact: Software Engineering Center for Telecommunications Department of Computer Science Engineering The University of Texas at Arlington Box 19015 Arlington, Texas 76019 Phone: (817) 273-3785 Fax: (817) 273-3784 E-Mail:se_phd@homer.uta.edu -------------- Preliminary Application Form ----------------------- Name: Address: Business Phone: Home Phone: Fax: E-mail address: Major: MS Thesis Title and Supervisor (if applicable): Current Institution: GRE verbal: GRE quantitative: List the computer-related courses that you have taken: -------------- Please e-mail this form to se_phd@homer.uta.edu ------------- A------------------------------------------------------- From: Frances L VanScoy Subject: from comp.parallel Thought you might be interested in the following from comp.parallel. Frances Van Scoy, West Virginia University Subject: Re: Building parallel programming systems From: j.w.mcmanus@larc.nasa.gov (John W. McManus) Lines: 88 In article , Simon.N.Smith@cm.cf.ac.uk (Simon McIntosh-Smith) writes: -Cut- > As usual Greg's sharp wit cuts to the bone! As well as giving us all > some light relief, Greg's also pointed out a few fundamental problems > we are suffering in the academic community (as I'm sure he intended to > do - irony is one of the most effective methods of communicating > serious ideas!) > > At the recent 10th British Theoretical Computer Science Colloquium, > Martyn Thomas, co-founder of Praxis, industrial commentator and resident > on more boards than just about anyone, said the following (paraphrased > by me) > > "Academics in Computer Science are spending far too > much time developing tools. This is basically a > software engineering problem, which means that > industry is far better at it than academia. > Prototype tools are fine, but unless the ideas > BEHIND the tools are properly thought out and well- > defined, no-one (including industry) will be able > to take them any further. > > SO - academia - please spend less time developing > tools, and more time developing the theory. Let > industry take it from there." > > Now, Mr Thomas does have a point. While we might not like the idea > of industry reaping the benefits of all our hard-work (although > this could be the source of some much-needed industrial collaboration > and cash), most of our hard work is going to waste anyway, because the > tools we develop are on the whole unusable. At the moment > millions of dollars are being spent developing a plethora of different > parallel programming tools and systems, and what do we have to show for > it? > -Cut- > > Simon > Simon, I think that Mr Thomas had a broader view. I see two distinct points in his statement: 1) We (the academic & research communities) are not communicating with our customers (industry) enough to understand their needs. We keep building tools that focus on our research needs without considering the customers requirements. We focus on the problems that are interesting to us, in many cases duplicating existing research or overlapping with other ongoing research programs. We need to ask ourselves "What value is added by me doing this research?" I am NOT advocating that all research have a short term commercial goal or payoff, just that we make sure WE belive it is relevent. We need to ask ourselves some tough questions and belive in the value of what we are doing. We need to know what others in our field are doing and how are work is related. 2) We (the academic & research communities) aren't always completing what we start. We keep building tools that focus on our research needs without considering the final step. We need to complete the development cycle and transition these tools to the public (commercial or non-commercial) for general distribution. If you have developed a useful set of tools they should be completed (including testing and documentation) and transferred to the public domain. It is a shame to have developed all of these tools and then set them on a shelf to rust, or even worse have all the development effort duplicated by another person. I think Mr Thomas is correct. We need to regain some focus. Greg is also correct, we have hundreds of "tools" that solve the same subset of problems. John For the legally impaired - any comments made are my own and do not reflect an "official" response of the Information Systems Division, NASA Langley, NASA, the U.S. Government or the President. Likewise, their opinions should NOT be construed to be my own. :) j.w.mcmanus@larc.nasa.gov ---------------------- And here's the original. ---------------------- Subject: Building parallel programming systems From: gvw@cs.vu.nl Lines: 101 So you want to build yet another a parallel programming system? Great! There are hundreds out there, so clearly it must be a good thing to do. Here are some helpful hints: (1) Do not ever allow users to think about the logical and physical topologies of their programs separately. For example, you should make them do index calculations for distributed arrays by hand; it will encourage efficiency. At best, you can subtly discourage users from putting more than one process on each processor by offering them message-passing system in which addresses are (processor, local-process-id) pairs. (2) Use point-to-point channels as the basis for your model. Most users enjoy drawing plumbing diagrams for their programs (it reminds them of the good ol' days of unstructured flow charts), and keeping track of whether process (i,j) is supposed to use channel (i+1,j-1) , and pass channel (i-1,j+1) to its first-but-one child process, or vice versa. (3) It is very important that you do not include group operations, such as barrier synchronization and broadcast. Every time you do this, you ruin the academic career of at least one graduate student at every user site, who would otherwise write an entire thesis on how s/he implemented these operations using logical trees. If you do include them, group operations should require all processors to participate at once. Don't allow user to break the SPMD handcuffs! (4) Reproducibility is clearly a bad thing (if a program generates the same result twice, then obviously at least one of those runs has been wasted), so make sure your system's behavior is as variable as possible. One can also make a good argument against providing trace visualization tools, although it is hardly necessary to do so, since most such tools display a great deal of data, but very little information. (5) Don't include a debugger. This will encourage programmers to write bug-free code. It will also keep the number of users down, so you won't have to spend a lot of time on support. If you must include a debugger, make sure it only works with one processor. (6) Don't include I/O. Well, printf to stdout is probably OK, since you're not providing a debugger, but whatever you do, don't provide access to a file system. I/O just slows programs down, and let's face is: the more test files a program is run on, the more likely it is to encounter a bug in your run-time system. If you do inlcude I/O, make it the user's problem to ensure things aren't garbled. Real users will enjoy looking at the detailed workings of systems buffers. (7) Don't marshal data automatically. It's much better to require users to pack data into messages manually, since this will encourage them to use only small, simple data structures. Hell, you can even make this sound like an advantage ("Unlike System Splodge, our system does not incur the overhead of automatic data marshalling..."). (8) Make it as difficult as possible for users to determine what is affecting the performance of their programs. You would be embarrassed if users could find out that 72 of their run time was spent loading the same executable binary times... (A corollary of this is that vendors shouldn't include hard-wired LEDs on the side of the machine, since they will show everyone what isn't happening inside.) Programmable LEDs are more fun, and can be set to flash on and off a lot to simulate a more desirable reality. Besides, the only figures your users really want for their papers are speedup ratios; absolute performance is unimportant, particularly if you keep telling them that: (9) "A more intelligent compiler could easily optimize this case." This is a very useful phrase, and you should use it whenever you are discussing your system's (lack of) performance. It is naive to think that you should include some discussion of how such optimizing would be done; your readers will trust you. (10) Shared object or address spaces are a bad idea. In fact, shared data structures of any kind are a bad idea. One particularly bad thing about them is their usefulness: users will exercise them in so many different ways that your system is bound to break. Tell them what early FORTRAN coders told advocates of recursion: it's silly, and anyway you can emulate it by hand if you really want it. (11) Remember that natural languages, such as Journal English, permit ambiguity for a reason. Do not be ashamed to mix verb tenses in order to leave the impression that something you've been thinking about has in fact been implemented in some version of your system other than whichever one you are presently discussing. Vendors do it all the time; why should they have all the fun? (12) Finally, do not write any non-trivial applications on top of your system, and try to discourage users from doing it either. Remember that you're doing parallel programming, not software engineering (and certainly not physics). The Mandelbrot set (a heavy user of CPU cycles in industry), the Game of Life, matrix multiplication (or LU decomposition without pivoting if you really must show off), and the N-queens problem were good enough for your supervisor; they should be good enough for you. Brent Gorda Paul Lu Greg Wilson March 1994 A------------------------------------------------------- From: Linda Ibrahim Subject:CFP: 8th CSEE ******************************************************************************** Call for Participation ******************************************************************************** WHAT: 8th CONFERENCE ON SOFTWARE ENGINEERING EDUCATION WHEN: March 29 - April 1, 1995 WHERE: New Orleans, Louisiana WHO AND WHY: You are invited to participate in the 8th Conference on Software Engineering Education (CSEE). Educators, trainers, managers, and administrators come gather together to exchange ideas about how to enhance software engineering training and education. The CSEE attracts international participation and attendees come from industry, academia, and government. Our purpose is to influence educational directions, stimulate new approaches, promote collaboration, and generate interactive exchanges among all educational stakeholders. This year we plan to take a hard look at what we are doing in training and education, how we are doing it, and whether we're doing it right. Are we affecting practice? Are we improving both our educational process and the product? Are we aligned in our approaches? Come share your views, concerns, techniques, and experiences. SUGGESTED TOPICS: *Impact of education on practice: Have we been effective? How can we know? What metrics do (should) we have? Measurement in software engineering education, self-assessment, benchmarking, measuring benefits of alternative approaches. *Education and training goals: Are we teaching the true fundamentals? What are the true fundamentals? What is a "good" software engineer and (how) can we grow one? Recent curricula and certification developments, influence on computing curricula, industrial curricula, effects of quality standards, balancing theory and practice. *People: How can we educate for continuous learning and improvement? Encouraging managers and practitioners to learn; teaching professionalism, leadership, and teamwork; educating change agents; social profiles. *Process: Is process being taught? How? What knowledge and skills are required for process improvement? Training and educating for continuous improvement. *Technology: How can we teach design? Teaching reengineering, model-based software engineering, domain engineering, software reuse, architectures, software repositories. *Industry-academia collaboration: Are industry and academia in synch? Do we know the education customer and are we getting the requirements right? Perspectives of recent graduates, mechanisms for interaction and collaboration, (how) can academics keep up to date with industry, (how) can graduates practice what they've learned. *Training and education management: Managing the training process, conducting needs analyses, costing, build or buy, reuse in education, what makes a good educator or trainer, assessing course quality, managing learner resistance, early learning. *Delivery: New technologies, use of learning aids, experiences in distance learning, use of laboratories, evaluating delivery alternatives. SUBMISSION GUIDELINES AND PROCEDURES: We request papers that present new ideas or approaches or that describe practice and experience. We also encourage proposals for panels examining controversial topics and designed to facilitate audience participation. We welcome proposals for half- and full-day tutorials. We invite innovative suggestions for informal meetings such as workshops, poster sessions, or birds-of-a-feather sessions. Submit five copies of a paper or proposal. Put only the title and beginning text of the submission on the first page of a paper. Provide a separate cover sheet with title, all authors' names, affiliations, complete addresses, telephone numbers, and e-mail addresses. Accepted contributions will appear in the conference proceedings, published as Lecture Notes in Computer Science by Springer-Verlag. IMPORTANT DATES: Deadline for submissions July 15, 1994 Notification of acceptances September 9, 1994 Final versions due October 12, 1994 SEND SUBMISSIONS TO: Education Program Assistant Phone: 412 / 268-3007 Software Engineering Institute FAX: 412 / 268-5758 Carnegie Mellon University Internet: education@sei.cmu.edu Pittsburgh, PA 15213-3890 CONFERENCE CHAIR: Rosalind (Linda) Ibrahim, Software Engineering Institute Internet: rli@sei.cmu.edu PROGRAM COMMITTEE: Bernd Bruegge, Carnegie Mellon University David Carter, Texas Instruments Jorge Diaz-Herrera, Software Engineering Institute Chuck Engle, Florida Institute of Technology Anthony Hall, Praxis Rosalind (Linda) Ibrahim, Software Engineering Institute Soheil Khajenoori, Embry-Riddle Aeronautical University Jerome Pesant, Applied Software Engineering Centre Keith R. Pierce, University of Minnesota, Duluth Ron Radice, Software Engineering Institute Robert Steigerwald, US Air Force Academy Philip Trudeau, The MITRE Corporation Steve Wartik, Software Productivity Consortium Laurie Honour Werth, University of Texas at Austin Sponsored by the SEI in cooperation with the IEEE Computer Society and the ACM. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University. -------------------------------------------------------------------------------- 8th CSEE EXTENDED SUBMISSION GUIDELINES PAPERS: Both research and experience papers are welcome. Research papers should present new ideas, approaches, perspectives, empirical results or concepts that stimulate new ways of thinking about software engineering education and training. Practice and experience papers should describe education and training experiences, their significance, outcomes, insights gained, and lessons learned. Papers should include an abstract (up to 200 words) and descriptive keywords. The recommended length is 10-15 pages, but in no case should a paper exceed 20 pages. PANELS: Panels should examine provocative, innovative, or controversial issues. A debate or similar structure that facilitates audience discussion or participation is most desirable. Panels consisting solely of short paper presentations are not acceptable. Panels should have no more that 5 people including the chair, should last about 1 to 1 1/2 hours and, as a general guideline, position statements by panelists should take less than half the time alloted. Panel proposals should include a description of the topic, its significance, the names and brief background of the panelists, and full contact information of the panel organizer. TUTORIALS: We encourage proposals for tutorials. They have been a very popular part of CSEE in the past and are offered free to participants, as part of the conference registration fee. Tutorials should provide opportunities for participants to learn about any aspect of software engineering education and training. Half day or full day proposals are welcome. Proposals should include an outline of topics to be covered, any past experience with the tutorial, and brief background of the tutor. OTHER: We welcome ideas for workshops, poster sessions, birds-of-a-feather gatherings, or other informal sessions. Working groups might address any of the suggested topics; other areas might be proposed. Summaries of results and recommendations may be brought back to the plenary session. Proposals should describe the topic, its significance, approach to be used, expected participants, expected results, and time-frame desired. ------------------------------------------ A------------------------------------------------------- From: Bob Dufresne Subject: CFP: Symp. Quality Software Engineering Standards and Industry Second International Symposium on Quality Software Engineering Standards and Industry Queen Elizabeth Hotel, Montreal, Quebec, Canada, August 21-25, 1995 Sponsored by: IEEE Computer Society - Technical Council on Software Engineering In association with: IEEE Software Engineering Standards Committee IEEE Canada American Society for Quality Control (ASQC) Software Division Canadian Information Processing Society (CIPS) Applied Software Engineering Centre/Centre de Recherche informatique de Montreal (ASEC/CRIM) Call For Papers, Tutorials and Panel Session Proposals Symposium Theme: Software Engineering Standards: Aid or Hindrance? In the last 20 years over 250 software engineering standards (SES) have been developed by more than 50 International, national, professional and industry organizations. Applications of SES range from information processing, process control to safety critical. Some of the needs for future SES include: Seamless integration of SES with systems engineering standards Ability to apply SES to different levels of rigour by application type Integration of SES with Quality System standards Specification and measurement of product attributes of software. This second in a series of International Symposia on Software Engineering Standards aims to promote international cooperation among practitioners, educators, standards developers, regulatory organizations, industrial users and software engineering researchers. The symposium will focus on the effectiveness of software engineering standards and their future, particularly with respect to critical systems and the practical use of formal methods. The symposium seeks papers that will encourage research into the utility of software engineering standards, promote harmonization of existing and in-work software engineering standards, solicit concepts for the representation and organization of the software engineering discipline, share lessons-learned on the use of software engineering standards, identify needs to improve, consolidate, and extend software engineering standards, and improve the process for developing and maintaining software engineering standards. Submission Information Papers must be in English, typed in double spaced format and between 2000-5000 words in length. These papers must not have been published or submitted elsewhere for publication. Each submission should provide a cover page containing title, all authors' names, affiliations and complete mailing addresses and telephone numbers, together with a maximum 250 word abstract and keyword list. The first page of the paper should have the paper title and beginning text of the document. If the paper is accepted, one of the authors will prepare the final manuscript in time for inclusion in symposium proceedings and is expected to pre-register for the symposium and present the paper. Authors of accepted papers must sign a copyright release form. The proceedings will be published by the IEEE Computer Society Press. Panel Session Proposals and Position Papers should include the title, proposed chair, tentative panellists (including a short vita), a 2 or 3 paragraph description of the subject of the panel discussion together with a rationale for the panel. Panellists must have agreed to participate prior to the submission of the panel proposal. Experience Reports are intended to provide exposure for software engineering professionals of practical experiences in the development and use of software engineering standards. The contributors should submit a 4-6 page written description of the experience or case study and a one page summary of the project for a ten minute presentation at the symposium. The paper should be clearly identified as an experience report. The evaluation criteria for these submissions will be based on the relevance of the results to future direction of software engineering standards. Submissions of papers, experience reports, panel session proposals and position papers should include six copies sent to one of the Program Co-Chairs, addresses below. Blind refereeing will be provided by a minimum of three experts. Tutorial Session Proposals are solicited for both full-length, all day tutorials and also mini- tutorials of four hour length. Important Dates: Submission Deadline: January 15, 1995 Acceptance Notification: March 15, 1995 Camera-ready copy: May 15, 1995 For further Information about the Symposium, Contact: General Chair Joseph Cote Treasury Board of Canada Secretariat 300 Laurier Ave. West, 10th Floor Ottawa, Ontario, Canada K1A 0R5 Tel: 613-957-2496 Fax: 613-957-8700 Program Chairs John Harauz Ontario Hydro H12 D27 700 University Ave. Toronto, Ontario, Canada M5G 1X6 Tel. 416-592-7235 Fax: 416-592-8802 E-Mail: John.Harauz@hydro.on.ca Roger Fujii Logicon 222 West Sixth Street P.O. Box 471 San Pedro, California 90733-0471, USA Tel: 310-831-0611 Ext. 2420 Fax: 310-548-4870/5984 E-Mail: r.fujii@compmail.com Sharon Miller AT&T, Room 2L-507 101 Crawfords Corner Road P.O. Box 3030, Holmdel New Jersey 07733-3030, USA Tel: 908-949-2873 Fax: 908-949-7724 E-Mail: sem@hoqax.att.com Suggested Topics Papers, Tutorials, Panel Session Proposals and Position Papers are invited in the following suggested areas. Sector Standards Aerospace, telecommunications, defence, transportation, medical electronics, nuclear power generation, electronic funds transfer, process control, government Software Engineering Process Configuration management, quality assurance/systems, user and software requirements, design and development, code, test, verification and validation, integration, project management, documentation, qualification of procured software products Special Topics Safety, reliability, security, maintainability, usability, privacy, formal methods, languages, tools, multimedia, human factors, networks, product and process metrics, conformance assessment, certification, criticality levels Standards Relationships Quality system standards, system engineering standards, hardware engineering standards, process improvement and TQM models, communication standards, regulatory bodies and law, Open Systems Interchange standards, database and repository standards, security standards, PC standards E------------------------------------------------------------------- FASE Volume 4 Number 12 Send newsletter articles to fase-submit@d.umn.edu or fase@d.umn.edu Send requests to add, delete, or modify a subscription to fase-request@d.umn.edu Send problem reports, returned mail, or other correspondence about this newsletter to fase-owner@d.umn.edu or kpierce@d.umn.edu You can retrieve back issues by anonymous FTP from from ricis.cl.uh.edu. You can access them through WWW at URL http://ricis.cl.uh.edu/FASE/ Keith Pierce, Editor Laurie Werth, Advisory Committee Department of Computer Science Dept. of Computer Science University of Minnesota, Duluth Taylor Hall 2.124 Duluth, MN 55812-2496 University of Texas at Austin Telephone: (218) 726-7194 Austin, Texas 78712 Fax: (218) 726-6360 Telephone: (512) 471-9535 Email: kpierce@d.umn.edu Fax: (512)471-8885 Email: lwerth@cs.utexas.edu