Forum for Academic Software Engineering Volume 3, Number 9, Tue Dec 21 11:15:24 CST 1993 (FASE # 19) Topics: A CONFERENCE IN SCOTLAND Summer Faculty Fellowships with NASA Re: Testing Announcing INFOSYS formal methods teaching workshop RE: Schach text A------------------------------------------------------- From: M_STAFF_VP@southampton-institute.ac.uk Subject: A CONFERENCE IN SCOTLAND Keith, I was asked by a collegue to mention to you that the British Computer Society (BCS) togrther with Wessex Institute of Technology organize a "Software Quality Management" coference in Scotland. It takes place in Edinburgh, 26-28 July 1994. (A similar conference was organized last year, too.)So, should somebody be over here in Europe in summer, they might consider to take part. Objectives: SQM 94 aims to promote international co-operation among those concerned with Software Quality Management by creating a greater understanding of software quality issues, and by sharing current research, academic and industrial experience. Conference Chairperson: Mrs J. Stapleton, BCS SQM Specialist Group, UK Conference Directors: Dr C. A. Brebbia and Ms M. Ross Organising Committee: R.A.Adey, V.Edgar-Neville, E.Gray, Dr.B.Samson, G.E.Staples, P.Wilkinson International Scientics Advisory Committee: R.L.Baber, consultant, Germany; H.Basson, University of Nancy, France; A.Chu, Logica Ltd., Hong Kong; M.Delaval, JRC Euratom, Italy; J.den Engelsman, GAK-IAD, Amsterdam, Netherlands; S.Hernandez, University of Zaragoza, Spain; R.Hunter, University of Strathclyde, UK; J.Kirakowski, University College Cork, Ireland; n.Panlilio-Yap, IBM Canada Ltd, Canada; M.St.Quintin, ACTC Technologies Inc, Canada; T.P.Rout,Griffith University, Australia; A.Torn, Abo Academy University,Finland; D.Wilson, University of Technology, Sidney. Australia. Conference Secretariat: Sue Owen, Wessex Institute of Technology, Ashurst Lodge,Ashurst, Southampton SO4 2AA, UK; Int E-Mail: CMI@ib.rl.ac.uk Conference topics: Contributions are invited on any of the topics below; papers based on practical applications are particularly welcome: Management topics: setting up a QMS; maintaining a QMS; Defect Analysis and Prevention; process improvement; quality planning; hypermedia for quality; TQM; human factors in quality management; financial aspects/measuring cost; audir systems; configuration management; risk management; training and educationfor quality; Software quality topics: approaches to software development; methodologies; prototyping; CASE technology; QMS software tools; quality metrics; testing and validation; inspection; software maintenance; application of formal methods;safety critical quality issues; External influencies: standards; company/process/product certification; legal considerations; natinal/european/world activities. CALL FOR PAPERS: papers are invited on the topics indicated above and others falling within the scope of the conference. Three topics of an abstract of no more than 300 words, clearly stating the purpose, results and conclusion of the work to be described in the final paper should be submitted to tyhe conference secretariat immediately for review. Eacg abstract should clearly state the most relevant conference topic to the submitted abstract. (fax: +44 703 292853 ) TUTORIALS: Five tutorials are planned to be arranged on Monday 25 July and Friday 29 July 1994 on the following topics: 1. Introducing ISO 9001 into a company. 2. Certification Standards and Schemes. 3. Configuration management and change control. 4. Software risk assessment. 5. Designing provably correct software in practice. CONFERENCE PROCEEDINGS: The Proceedings of the conference will be published in book form by Computational Mechanics Publications and will be available to delegates at the time of registration. In addition the proceedings will be widely distributed after the conference through the international book trade. So, should anybody be interested, get in touch with the organizers. (Or with me, I can always answer any inquiries or pas them to the organisers.) Vlada Petruv, Southampton Institue of Higher Education, Southampton, England A------------------------------------------------------- Subject: Summer Faculty Fellowships with NASA From: Gary Ford The National Aeronautics and Space Administration (NASA) sponsors a wide range of summer faculty fellowships. These might be helpful to a professor seeking insight into large-scale software engineering in an industrial environment. A brochure describing the fellowship program is available from: American Society for Engineering Education 1818 N Street, NW Suite 600 Washington, DC 20036 The application deadline is January 14. The fellowships are typically for ten weeks. They pay $1000 per week, plus travel and relocation allowances. Recipients must be US citizens and have at least two years of teaching experience. Below are a few examples of the research opportunities in computing- related topics at some of the NASA facilities. Goddard Space Flight Center (Greenbelt, MD) Simulations and modeling of Earth and space phenomena; high performance computing; global optimization algorithms and applications; simulated analogs; genetic algorithms; neural networks; intelligent data management systems; mass data storage systems, access, and retrieval; scientific visualization and animation; data compression. Jet Propulsion Laboratory (Pasadena, CA) Aplication of computer graphics and hypermedia to data visualization and human interfaces; next-generation data management systems, software engineering and management models, methodology and tools; fault-tolerant systems. Kennedy Space Center (Merrit Island, FL) Real-time systems for control and monitoring of complex checkout and launch procedures; distributing databases and computer networking; human-computer interfaces; adaptive control software. Johnson Space Center (Houston, TX) Computer-aided software engineering; knowledge-based system technology; knowledge acquisition, man-machine interface technology; multi- and hypermedia technology; mobile and pen-based computing; intelligent computer-aided training; virtual environment technology; neural network systems. A------------------------------------------------------- From: lwerth@cs.utexas.edu (Laurie Werth) Subject: Re: Testing FASE is looking good - thanks for the hard work. I have some ideas on testing also, but it's been to frantic to write. I have two approaches: 1. Give students an existing project from a previous class. Start by testing, using defect tracking and CCB to control maintenance. Then add new features. I cover testing techniques the first half - roughly and analysis and design the second half in this model. 2. Have small teams develop one or more small systems using various analysis and design methodologies, including screens - roughly the first half. then Testing an existing piece of software the second half - this semster we tested TurboCASE. Each team takes a part of the syystem - in this case teams took DFDs, Data Dictionaries and Process Specifications, Real-Time extensions, esp FSM and Decision tables, Structure Charts, ER diagrams and Class/object models. They can't do unit testing since we don't have the code (Notice that we haven't coded at all.) We do an IEEE standard test plan, dest case design spec, test cases, results, and summary report. The IEEE standard includes two examples and I carry over examples from the previous semester - all is collected in a notebook at the end and a presentation is made on their results the last seek or so. They do system tests (functional, validation (user's manual was spec), performance, stress, volume, recovery etc.) and usability testing (surveys etc of users) The students seem more aware of themselves as computer software users - they were properly indignate that roughly 8% of their test cases failed on version 4.22 of a commercial product. I can run version two with two classes and still have time for my Software Engineering project which emphasises software process in which we do software engineering tools. We have done a defect tracker and are currently working on a software metrics analysis tool - both the SEI (tech report) specifications. We follow IEEE technical and process standards and are rigorous about baselining, control change via the CCB etc. Each student is on one technical team and one process team, using a matric organization. The test team tests the requirements and design specs as well as the user's manual. The TA is the External Auditor. They take their responsibility very seriously for the most part - tho we have time for some team building high jinks. The time I put in on team building in all versions of the class really pays off in improved quality of documents and code. I hope to see you at the SEI meeting in San Antonio in January. Laurie A------------------------------------------------------- From: D.Viehland@massey.ac.nz Subject: Announcing INFOSYS Announcing INFOSYS - The Electronic Newsletter for Information Systems INFOSYS is an electronic newsletter for faculty, students, and practitioners in the field of Information Systems. INFOSYS publishes news items, requests for assistance, announcements of professional meetings and conferences, position notices, a calendar of upcoming events, comments on recent publications, abstracts of papers that authors are willing to share, and other items of interest to the Information Systems community. INFOSYS is published biweekly, more frequently if volume requires it. INFOSYS operates as an electronic mailing list on listserv software at American University in Washington, DC. The editor is Dennis W. Viehland (d.viehland@massey.ac.nz). To subscribe to INFOSYS send the following one-line e-mail message to listserv@american.edu: subscribe infosys yourfirstname yourlastname (e.g., subscribe infosys john smith). You will receive a welcome letter that will tell you more about INFOSYS and listserv. The first issue will be published in January 1994. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Dennis W. Viehland D.Viehland@Massey.ac.nz Senior Lecturer (06) 350-4213 Information Systems (06) 350-5233 (messages) Massey University (06) 350-5611 (fax) Palmerston North, New Zealand * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * A------------------------------------------------------- From: peters@mozart.uark.edu (James Peters) Subject: formal methods teaching workshop Hi, Keith! I've attached to this msg an announcement you might find interesting. --Jim TEACHING FORMAL METHODS CURRICULUM DEVELOPMENT WORKSHOP Hamilton College Clinton, N.Y. July 30 - Aug 5, 1994 sponsored by The National Science Foundation THE PURPOSE OF THE WORKSHOP is to develop modules and materials for teaching formal methods in an undergraduate setting. Participants will be asked to submit a module or position paper which they have developed. While the particular form and length of the module is left unspecified, modules should contain both expository material and exercises or labs. TOPICS for the modules may include(but are not limited to) -- Propositional/ Predicate Calculus , with applications to assertions/pre- and post-conditions -- Loops and Invariants -- Category Theory -- Algorithm Design -- Hardware Specification/Design/Verification -- Parallel Constructs (eg. CSP, Hoare semantics) -- Operational Semantics -- Formal Methods with OOP -- Applications of Mathematica THE WORKSHOP itself will be devoted to the presentation, discussion and revision of participant modules. We also anticipate inviting several keynote speakers. After the workshop, participants will be asked to submit full revised versions of their modules for incorporation into a collection for dissemination to computer science educators. Three of the principal investigators for the project, Philip Mulry (Colgate University), Doug Troeger(CUNY) and Henry Walker(Grinnell College), will be responsible for editing the collection of materials with a view towards publication in the near future. We plan to have a followup workshop in the summer of 1995, in conjunction with the working group in Object Oriented Computing, to evaluate the results to date and further disseminate the materials developed. Participants will be encouraged to use draft versions of the modules in their teaching for evaluation. AN NSF GRANT will cover travel, room and board costs for the workshop. Participants will receive a stipend of $150 for their participation in the workshop and an additional $150 after submission of their revised module. THERE MAY BE LIMITED FUNDS to support attendance by individuals who want to become involved with the project but do not have a module to submit at this time. Please write to inquire. TO APPLY: Send an abstract of your module or position paper and a brief resume including your experience with formal methods to: Philip Mulry Formal Methods Workshop Computer Science Department Colgate University 13 Oak Drive Hamilton, New York 13346 email:fmworkshop@cs.colgate.edu ABSTRACTS should be no more than 5 pages in length, be clearly written, and provide sufficient detail to allow the program committee to assess the merits of the module. The preferred mode of submission is via email. The preferred abstract format is latex. Submission of abstracts should be received by February 20, 1994 by the program chair. This is a firm deadline, late submissions will not be considered. Participants will be notified of acceptance by March 20,1994. Accepted modules (in a specified format) will be due July 1,1994. A final revised module will be due November 1, 1994. DATES: Abstract Submission Deadline: February 20, 1994 Participation Notification: March 20, 1994 Draft Module Due: July 1, 1994 Conference: July 30 - August 5, 1994 Revised Module Due: November 1, 1994 FOR FURTHER INFORMATION, contact the Workshop Co-chairs: Philip Mulry: phil@cs.colgate.edu Doug Troeger: dtroeger@csfaculty.engr.ccny.cuny.edu Henry Walker: walker@ac.grin.edu A------------------------------------------------------- From: srs@vuse.vanderbilt.edu (Stephen R. Schach) Subject: RE: Schach text In the last issue, Brian Marick responded to Keith Pierce's posting "Getting students to plan for testing" in the November 19 issue by tactfully mentioning his new book. Since the original posting by Keith Pierce mentioned one of my books, I should like to respond, equally tactfully, to his original posting. In his posting, Keith Pierce wrote: >I just finished grading team projects produced in our senior software >engineering class, and, once again, I'm not happy with the products. >Once again, despite my constant protests in class, most teams skimped on >specifications and design, and rushed to coding to "get something >running". I was surprised to read further about >Our present text, by Schach, because that text ("Software Engineering" by Stephen R. Schach, Second Edition, Irwin, 1993) _explicitly_ solves that problem. The Term Project is broken into 15 separate components. At the end of Chapter 7, the teams do the specifications, at the end of Chapter 8 the software project management plan, at the end of Chapter 9 the design, and so on. If Keith Pierce is using that book, there is no way that the teams can possibly "rush to coding." Furthermore, at the end of Chapter 12 they are required to draw up the black-box test cases _BEFORE_ they do the implementation at the end of Chapter 13. While Keith Pierce is correct that the specific words "test planning" do not occur in the text he has adopted, his students are forced to do it in Chapter 12, and thus they see the importance of selecting test cases before implementing the product. Then, when the teams finally implement the Term Project (Chapter 13), they are told (page 445) "remember to use the black-box test cases you developed in [Chapter 12]". Furthermore, I cannot understand why he states: >The conventional attitude of students is "lets run it a few >times to see if it works." When it works a few times, they think they >are done, and hand in the product. For this last project, several teams >submitted voluminous output of a few test runs, but without any >annotation of what the test run was supposed to prove. This makes little sense to me because in the component of the Term Project in Chapter 12, the students are told (page 416), "For each test case, state what is being tested and what the expected outcome of that test case is." If his students are indeed using the text by Schach, then there is no way that what Keith Pierce has described can happen--component 12 of the Term Project specifically prevents that. Keith Pierce continues: >... What should we >test for? What cases are likely to find flaws? What is the anticipated >output of a test case? How do we verify that actual output matches >anticipated output? Is the coverage complete? All those questions are answered in the text he has chosen, starting in Chapter 5, Testing Principles, and continuing in the succeeding chapters--testing during each phase is discussed in the chapter on that phase. It is true that they are not answered explicitly under the heading of test planning, but they are answered, nevertheless. >Where can I find guidance for my students in going about test planning? The second edition of Schach, "Software Engineering" has been so widely adopted that a third edition is being prepared. Professor Pierce is correct that the phrase "test planning" should not have been omitted from the current edition. I can assure him that the phrase will appear in the third edition, and that all the material relating to test planning will be explicitly tied to that phrase. E------------------------------------------------------------------- FASE Volume 3 Number 9 (FASE # 19) 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 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