Forum for Advancing Software engineering Education Volume 8 Number 02 - February 15, 1998 670 subscribers Note: If you have problems with the format of this document, try +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Letter from the Academic Editor Comments about FASE format Atlanta Bound! This Month's Topic: The Personal Software Process in Education and Training Next Month's Topic: Software Education Upcoming Topics News Items Software Technology Review Journal of Systems and Software - Special Issue PSP Studio at East Tennessee State Software Process Improvement Text Published Calls for Participation ASE'98 Conference on Student Projects Conference Paper Survey Conference Announcements CSEE&T BOF on Education Journal Summer School on Reliability and Safety of Human-Machine Systems DEXA '98 International Workshop on Large-Scale Software Composition Faculty Positions Texas Tech University (chair) Embry-Riddle Aeronautical University The University of Namur, Belgium The University of Hawaii at Hilo (visiting) Contact and General Information about FASE +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Don Bagert Letter from the Academic Editor First of all, I want to thank Tom Hilburn for the great job he did as guest editor this issue on the topic of the Personal Software Process (PSP). The editors really appreciate people like Tom, without whom we wouldn't be able to give you these monthly forums! Okay, this month, I've got several topics, so I'm actually going to break down my letter into a couple of sections. ####################################################################### Comments about FASE format Okay, last month's letter by me was about the FASE mailing format, the use of the web for FASE distribution, and the size of each issue. I was fortunate enough to receive several letters of feedback from you, our readers. Rick Zaccone suggested that we put < > instead of parentheses around URLs, e.g. , since some mailing software parses such text better. I am going to try it for both URLs and email addresses for those that I myself place in each issue. (I generally try not to change the format of what others have written for inclusion in FASE, except where absolutely necessary.) Let me know what you think. Kenneth Jacker suggested using an email digest format that some email readers could view in "digest mode". Kenneth was nice enough to supply me an example, which was used in a recently SIGCSE.MEMBERS digest. I wasn't (and am not still) very familiar with that format, but we're looking at it. If you're familiar with this email digest format, I would appreciate some feedback. Thanks! I did have a couple of people make suggestions about the size. One person suggested that issues over a certain size be separated into two parts, to accommodate those email software systems that can't handle files over a certain size. I'm happy to do that, if it doesn't cause problems for those of you that save issues of FASE (obvious collectors' items ;) over time. Please let me know if you have a problem with (or support) splitting issues into two parts. Another person suggested that the bulk of the announcements be shortened, with a URL pointer to the entire text of the message. I have been reluctant to do that, since there are still some people who have email, but don't have access to the web. Or am I too far behind the times? Please let me know. Finally, please note the new guidelines for submission format at the end of this issue under "Contact and General Information about FASE". These guidelines are intended to prevent delays in distribution of this publication, which have especially occurred during the last two months. Thanks! ####################################################################### Atlanta Bound! Well, in a few days I'll be leaving for Atlanta, to attend 1) the Working Group on Software Engineering Education and Training meeting on February 21-22, 2) the Conference on Software Engineering Education and Training (CSEE&T) on February 23-25, 3) the ACM International Collegiate Programming Contest (ICPC) Regional Contest Directors' Symposium on February 25-27, 4) the ACM SIGCSE Symposium on Computer Science Education on February 25-28, 5) the ICPC World Finals on February 27-28, and 6) the ICPC Steering Committee Meeting on March 1. Whew! At least there will be a lot to report on next month! I hope to see you in Atlanta, and then here next month (I hope!) Don +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This Month’s Topic: PSP in Academia and Training by Tom Hilburn, Professor of Computer Science, Embry-Riddle Aeronautical University (hilburn@db.erau.edu, http:/erau.db.erau.edu/~hilburn) This month’s topic concerns the Personal Software Process (PSP). In this section we include contributions from faculty that have developed are delivered PSP material in different formats (tutorial, one week short course, part of a freshman course, or a full course at the senior/postgraduate level) and for students with varying backgrounds (freshman and advanced students in CS/CE/IS, practicing software engineers, software managers, and college faculty). Although many of you may be familiar with the PSP, for those that may not know much about it there is a section at the end of the contributions about PSP, titled "What is the PSP?", that provides introductory information about the PSP. This section also includes a list of PSP references. My own experience with PSP began in 1994 when I sat in on a graduate course in PSP (in our MSE program) taught by one of my colleagues (Soheil Khajenoori). This course is now part of the core in our MSE program and other courses in the program build off of the experience that students gain in using and developing a defined software process. Since then we have introduced PSP concepts and practices into our undergraduate CS program. We start with PSP in the first year, continue with PSP in the second year, and in their final year our students use PSP as part of a team process in a senior project course. We think that the PSP can be extremely valuable in helping students to develop good software development practices, and although we have learned a lot about how to do it (or what not to do), we are still struggling on the "how and where" part of integrating PSP into our curriculum. I believe one of the most valuable parts of having my students use the PSP, is the insight I gain when examining their PSP data. I can see what is working for them and what is not, and I able to give them more focused and useful advice on how to improve their performance. Last year I spent a year at the SEI working in the Process Group. One of my jobs was to assist in developing PSP training material for industry and to help in the general area of planning for transition of PSP into industry and academia. The interactions I had with industry software engineers and trainers re-enforced my understanding of the problems with large-scale software development and the importance of process in effective development. I feel that PSP can play a crucial role in helping software engineering to mature as a discipline. Another task I worked on at the SEI involved developing and delivering a PSP workshop for faculty. The objective of the workshop was twofold: teach faculty about the PSP; and help them prepare for teaching a PSP course or integrating PSP into their curriculum. Embry-Riddle and the SEI delivered the workshop to twenty-two faculty in June of last year. The attendees all said they thought it was valuable, however, I probably gained the most - the workshop discussions between faculty about the PSP and how one teaches good software engineering practices has had a significant effect on my approach to teaching a software engineering project course this fall. Students in the course used a team process based on the PSP to develop a software product - it was the most successful approach I have had in five years of teaching this course. We are planning another workshop this summer and if you are interested just send me an email note. You can look for announcement in the March issue of FASE. ####################################################################### Using PSP in CS/2 and Applied Programming Classes by Ralph F. Grove, Ph.D., Assistant Professor of Computer Science, Indiana University of Pennsylvania (rfgrove@grove.iup.edu , http://www.co.iup.edu/~rfgrove) In the fall of 1997 I worked with adapting PSP for use in CS/2 and applied programming classes. My objectives were to use the data produced with PSP to help students learn the value of methodology. I've found that teaching good programming methodology is difficult in these classes. Students tend to code first and design later, and convincing them to do the opposite is difficult. From the PSP data, however, students learned that following a methodology that includes design and review steps can reduce debugging time and produce higher grades! The classes involved included two sections of a data structures course which used C++ and one section of an applied programming course which used COBOL. A reduced version of the PSP was introduced with the first programming assignment, including time logging and a time summary. About 30 minutes was spent in class reviewing the forms and walking through a practice scenario in order to introduce the forms. Still, students had problems understanding how to use the forms correctly as they developed their first project. With the second assignment, additional time was spent reviewing the forms, and a lines-of-code (LOC) summary was introduced. Students did much better with this version of the forms. With the third assignment, an error log and error summary was added to the forms. This much data collection proved to be too demanding for most students and the quality of data collected was reduced as a result. For the remaining assignments of the course, only time and LOC data were collected. Following the completion of each project, students were presented with a summary of data collected via the PSP forms. Unfortunately, the format doesn't allow me to show the graphs which students saw, but I'll do my best to describe them. One remarkable (to the students) revelation was that spending time on design and review could reduce debugging (compile and testing) time during program development. This became obvious from a graph showing compile + test time vs. design + review time. Those students who spent the most time in design + review spent the least time debugging and the least time overall. The second revelation was that students who spent relatively more time in design + review tended to get better grades on their projects (grades were assigned before any of the PSP data was processed, to eliminate subjectivity on my part). This relationship was demonstrated by a graph showing project grade vs. the ratio between design + review and compile + test times. After viewing these graphs, students were able to come to the above conclusions on their own. As Watts Humphrey would say, I let the data do the talking! ####################################################################### Teaching PSP at Old Dominion University by Mike Overstreet, Assoc. Prof. of Computer Science, Old Dominion University (cmo@cs.odu.edu) We've been using Watt Humphrey's PSP text for three years in a required software engineering course for computer science and computer engineering majors. The course is offered once a year with enrollments of 62 (last fall), 60, and 51 for these years. The PSP text will be used again next fall, though the way PSP is used has changed with each offering and I'm sure I still don't "have it right." Let me give a brief description of Old Dominion University and the course. Old Dominion is a state-supported school in Norfolk, Virginia, with about 16,000 students. Our department has about 200 undergraduate majors, 100 MS and 35 PhD students. As an urban university, many students work (in my OS class this semester, 42 of 50 students work full- or part-time). We never have sufficient TA support to cover all grading and recitation needs. The pragmatics of class size and TA support influence how the PSP assignments are evaluated and the quality of feedback provided students. Students have completed a standard data structures course before taking this course; it in turn is a prerequisite for an intro operating systems course. This software engineering course is a one semester 4 credit course with 3 lecture hours and 2 hours of recitation per week. Recitations are capped at 20 each (to offer "small" classes). If you've looked at Humphrey's text, you've seen that he provides two sets of programming assignments. I have only used the first set. Each set contains 10 programming assignments and are used to build the complete personal software process. In a 15 week semester, this means that students essentially must complete an assignment a week: I don't have an assignment due the first or last weeks; I also give two hour-long, in-class exams and no assignments are due these weeks. PSP is essentially form-driven; each assignment requires the completion of several forms; the complexity of these forms increases over the 10 assignments as more of the process is introduced in each new assignment). Most students find the forms irritating; on the from they are required to complete, they report the time spent ospent dealing with the forms; several students report spending more time completing forms than the rest of assignment. I'm skeptical, and suspect the high numbers for completing the forms in part reflects the students' dislike of them. Humphrey's recommends that instructors complete the 10 assignments before offering the course. This is an excellent idea, but I didn't do it (publish or perish lives!) I mention this because the first time through, I feared that our undergraduate students could not work at this pace (they're not CMU grad students with significant programming experience, after all) and so had assignments due every week and a half. Talking to students at the end of the semester, I learned that they found the assignments easy. Perhaps this was bragging but the class averaged 5.3 hours per assignment (dagain, data from PSP forms). This is low for a project oriented course. So the next offering, I used all 10 assignments (but still somewhat timid, I made the 10th assignment extra credit). Like many schools, we conduct exit interviews with graduating seniors where they are encouraged to critique the courses they took. Students who had been though the PSP version of this class reported feeling cheated in not being involved in a large programming project; they felt unprepared for work since they had only coded "toy-sized" assignments. In previous years (before PSP) students had completed a large team project in this class using an 100 page requirements spec from NASA Langley. I agree with these comments. So on the third offering last semester, I had students complete only 4 of the PSP assignments. This took the first six weeks of the course. They then switched to a large team-based term project. While the complete PSP process was not covered, enough had been so that students could then apply what had been covered to the large project. A few summary comments for those considering PSP. - The Powerpoint slides (prepared by Humphrey and available from the publisher) were a real advantage to me; I could edit them as desired and made heavy use of them. - The standard set of programming assignments (set A) has students building some statistical tools, such as linear regression and confidence interval computations. Our degree program has a stat requirement but many students have not taken it before this class. I found this no real disadvantage since all of the statistics they use has intuitive meanings easily explained; students were able to cope with little trouble. Students then use these tools for scompleting forms required in subsequent assignments; a real advantage. - While each assignment is a complete program, they are nicely coupled so that all of the preaching about the benefits of reuse are reinforced here. - A key part of this course is allowing students to see how their personal data (never made public) compares with their class members. Humphrey plans for students to be given individual spreadsheets for each assignment which includes their data and the class averages. These spreadsheets also allow the student to see how their performance improves over the course in terms of, for example, productivity (measured in lines of code produced per hour) and quality (measured in errors per thousand lines of code). The intent is that the student sees -- through his or her own data -- that the time spent on careful design and code reviews reduces the time required to complete the assignment and also results in a higher quality product. We were not able to provide this type of feedback; it was a challenge for the grader to keep up with the weekly programming assignments. - I very much like PSP's use of a few simple software metrics which students gather about their own products and performance. - I found it difficult to generate enthusiasm (or even mild interest) in the project planning and management topics of PSP. This may reflect the lack of work experience of our undergraduates so that they do not understand their importance. (Or it reflect my lack of interest -- as much as I try to pretend.) - PSP focuses on only part of the software life cycle; students are again left with the erroneous impression that code generation is the main activity in software development. - The content of the PSP text is not a problem for our undergraduate students though it is described as a graduate level course. - Student concerns about not having enough experience working in groups and not working on a large project are legitimate, particularly in an undergrad program. So what's the summary of all of this? I will use PSP again for the undergraduate course, but I'll combine it again with group projects on a large assignment where students apply what they've learned on the "toy" assignments to a larger problem. ####################################################################### Assessment of Industrial Implementation of the PSP by Iraj Hirmanpour and Soheil Khajenoori, Department of Computer Science, Embry-Riddle Aeronautical University (iraj@db.erau.edu, soheil@db.erau.edu ) Introduction We have been involved with the industrial implementation of the PSP for the past three years. In this article, we share our experiences of assessing our implementation of PSP in industry. We first discuss how we have evaluated effectiveness of introducing the PSP in large organization and show results obtained thus far. Admittedly, our sample is small and our conclusions are preliminary as we are continuing with data collection and analysis. Until recently, most of the data on the PSP successes was based on academic classroom experiences at Carnegie Mellon and Embry-Riddle Aeronautical University, among others. Data from classes at both of these institutions have shown a high rate of success in terms of course objectives -- improved product quality, increased programmer productivity, and enhanced ability to estimate size and effort as is measured by classroom exercises. A question that remains is, does this "skill gains" transfer into the work place and can such benefits be achieved on real projects. PSP Assessment We have experience with training over one hundred engineers in two different corporations in six business units, following work of these engineers after the PSP training, and collecting data. To assess effectiveness of the PSP training, we have adapted the Kirkpatrick’s [Kirkpatrick 94] four-level assessment methodology. The four levels represent a sequence of ways to evaluate programs and represent a hierarchical approach to program evaluation and they area: In what follows, we describe how this assessment framework was used to evaluate PSP training: Level 1: Evaluating Reaction - assessment that measures how those who participate in the program react to it. An anonymous survey conducted at the end of the course was used to make the assessment. This survey sought to determine participants reaction to the course, the learning experience, and engineers perspective of the applicability of course materials to engineers work. The written questionnaire consisted of two sections: the first dealing with opinions; the second dealing with work habits. The engineers were asked to answer each question on a scale of 1 to 10, where 1 is low and 10 is high. Sample questions included: - "To what degree do you think the PSP concepts are related to the software engineering discipline?" - "To what degree do you think the course has helped you to better understand software process improvement concepts in general?" - "To what degree do you think PSP concepts have convinced you about the importance of following a defined software process?" - "To what degree has your personal data helped you to gain insight into the way you develop software" - "To what degree have PSP and your personal data helped you to improve your personal software process?" - "How many hours per week, on average, do you spend on the PSP course (class, readings and assignments)?" Level 2: Evaluating Learning -- evaluates the extent to which participants change attitude, improve knowledge, and/or increase skill as a result of attending the program. This assessment was made by analyzing the students’ performance in each class based on data generated by class assignments. This data provides information on productivity, defect rate, estimation and scheduling accuracy. Level 3: Evaluating Behavior -- evaluates the extent to which change in behavior has occurred due to the training program. For assessment of level 3, a survey instrument consisting of a written questionnaire, was administered to each graduate five months after the course to determine if behavior change occurred as a result of the course. Level 4: Evaluating Results -- assessment focuses on the final results that occurred because the participants attended the training program. Metrics from actual software development projects, completed after the course by PSP-trained engineers, were analyzed to assess the benefits gained and the results obtained. Data currently are from eighteen projects performed by six engineers after completing the PSP course. These projects are short duration, one to three person projects and are a combination of maintenance and new developments. Projects are all written in C programming language with their size range from 20 to 4500 Lines of Code (LOC) and development time range from 3 to 955 hours per project. Results Results obtained thus far based on each level of the framework are presented below. Level I: Evaluating Reaction Analysis of the questionnaire revealed that ratings of all questions on the questionnaire exceeded a rating of 8; over 60% of the questions were rated 9 or above. The survey also showed that students spent 11 to 15 hours per week on the course. Level II: Evaluating Learning To measure the knowledge and skill acquired by participants, students’ performance in terms of product quality (defect rates) at the end of the course was compared with their performance at the beginning. This data was drawn from the PSP programming assignments. The metrics used in this study were compiled by averaging the defect rates (total defects and defects found during testing) of the twenty-four students for programs 1, 2, and 3, as the indicator of the baseline metrics, and averaging the defect rates for programs 8, 9, and 10, as the end-of-course results. The average defect rate of the two classes decreased by 28% as a result of the PSP education. Class 1 showed slightly more improvement than did Class 2 (29% to 20%). Test defects measured at the beginning of class and again at the end of class reduced, on average, by 63%. Class 1 and Class 2 showed roughly the same level of improvement (63% to 62%). Level III: Evaluating Behavior The question most germane to this Level is "What proportion of the graduates of the course actually apply PSP concepts to real programming tasks?" Five months after the completion of each course, a survey was conducted to gauge the trained engineers’ continued use of the software engineering practices taught in the PSP class and to seek the engineers’ opinion about the value of the course. The population surveyed is the 24 engineers who graduated 6 months ago or longer. The results of the survey show that 87% of the engineers reported a better knowledge of quantitative process improvement as a result of the course; 79% reported that they now pay more attention to defect management than before taking the course; 87% reported that they now conduct code reviews; and 70% reported better insight into project progress than before taking the course. The second part of the survey was designed to identify behavior change as a result of the PSP course. PSP graduates were asked to record their opinion before PSP training and their opinion after PSP training. Self-reported changes in the work habits of the engineers since the PSP class are graphed in Figure 3. As shown, the percentage of engineers reporting adaptation of new practices increased in all categories: defect management practices increased from 27% to 82% after the class, planning increased from 48% to 87%, use of time management increased from 26% to 57%, personal code review increased from 35% to 83%, and use of data for estimation increased from 58% to 88%. These reported increases suggest that PSP-trained engineers are adopting more of software "best practices," with a potential concomitant increase in efficiency and quality. Level IV: Evaluating Results For the eighteen projects, the average test defects were 5.4 defects/KLOC. This shows improvement when compared to the average test defects for the last three assignments in the course (14 defects/KLOC). Similarly, total defects/KLOC of the eighteen projects were 23, while total defects/KLOC of the last three programming assignments in the course was 52 (see Table 2); a 55% improvement. The number of defects found during testing (test defects) of each engineer on actual projects completed after the course was then compared with the class performance of each engineer on the first three projects, and again, on the last three projects. Defect rate for Engineer, for example, 1 went from 12.8 defects/KLOC on the first three class assignments, to 11.5 defects/KLOC on the last three class assignments, to 4.5 defects/KLOC for the four projects completed after the course. Likewise, Engineer 2 went from 30 to 20.2 on the class projects to 2.3 on six actual projects. Engineer 3 went from 33.7 on the first three assignments, and averaged 3 on the three actual projects completed prior to analysis (no data is available for the last three class assignments). Also the test defect rate of the six engineers, averaged, has declined since the inception of the course by 85%. This is specially important since the number of defects remaining in the product is directly proportional to the number of defects found during the testing, hence the decline in test defects has a high impact on the quality of the software products delivered to the customer. Conclusion With experience of training over one hundred engineers, following their work, and collecting data, we have learned that gains obtained as result of classroom learning not only extends itself into the work place, but we also observe a continuous improvement phenomenon. Engineer’s productivity increases as one repeats the same process and learns from it. Software products produced by the 18 projects analyzed in this study have been in use, by the customers, for at least six months and as of the time of this writing only one field defect has been reported. Insertion of PSP into software engineering practices of an organization is a complex and difficult task. Successful implementation requires extensive planning, culture change activities and quality training. The benefits, as our small sample has shown have far reaching implication in increasing quality and reducing cost of software product. Acknowledgment: The authors would like to acknowledge contributions of Watts Humphrey, our mentor and inspirer, for his contribution to our understanding of many subtle points inherent in PSP implementation. ####################################################################### What is the PSP? The PSP was developed at the Software Engineering Institute (SEI) by Watts Humphrey. It is designed to bring discipline to the practices of individual software engineers. The PSP provides students and practicing software engineers with a framework for measuring and analyzing their development work so that they produce programs of higher quality and in a more predictable manner. More specifically the objectives of the PSP are as follows: - To introduce students and engineers to a process-based approach to developing software - To show students and engineers how to measure, estimate, schedule, and track their work - To show students and engineers how to improve the quality of their programs The concepts, structure, and activities of the PSP are described in detail in the textbook , "Discipline for Software Engineering” [Humphrey 95a] The following quotes from Humphrey’s book, which are addressed to a student using his book as a text, best characterize the purpose and scope of the PSP: "The PSP’s sole purpose is to help you be a better engineer. ... It can help you plan, better track your performance precisely, and measure the quality of your products. Whether you design programs, develop requirements, write documentation, or maintain existing software, the PSP can help you do better work. ... The PSP is not a magic answer to all your software problems. Although it can suggest where and how you can improve, you must make the improvements yourself." The "Discipline" text (along with the instructor support materials ) is the basis for many courses taught in industry and in academia (at the senior/graduate level). Although the components of the PSP are not complicated and they are based on sound engineering principles, both teachers, students, and engineers have found that learning PSP is a demanding and challenging activity. It requires a great deal of effort (120 hours or more), applied in a disciplined and committed manner. The PSP provides an incremental approach. It includes seven PSP processes can be grouped into four process levels that have following focus: - PSP0: establish a measured performance baseline - PSP1: make size, resource, and schedule plans - PSP2: learn defect and quality management - PSP3: scale up PSP methods to larger projects The processes are said to be "defined" since that include precise and unambiguous procedures for carrying out the process. Each process is structured into a set of processes phases; each phase has a script that gives a step-by-step description of the tasks to be completed; and there are forms and documented standards that are used in carrying out the process tasks. There is also additional guidance and advice on how to analyze and improve one’s process. Humphrey has also written an introductory PSP text [Humphrey 97] that is intended for beginning programmers. It is currently used by a number of schools as part of introductory courses in software development. In addition to the article by Hirmanpour and Khajenoori, two other sources listed in the refences [Ferguson 97, Hayes 97] provide data about the value of PSP training and it application in industry. PSP References [Ferguson 97] Ferguson, P., et. al., Results of Applying the Personal Software Process, Computer, 30, 5 (May 1997), 24-31. [Hayes 97] Hayes, W. and Over, J.W., The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers, CMU/SEI-97-TR-001, December 1997. [Humphrey 95] Humphrey, Watts S. A Discipline for Software Engineering. Reading, Mass.: Addison Wesley, 1995. [Humphrey 96] Humphrey, Watts S. "Using a Defined and Measured Process." IEEE Software 13, 3 (May 1996): 77-88. [Humphrey 97] Humphrey, Watts S. Introduction to the Personal Software Process. Reading, Mass.: Addison Wesley, 1997. [Kirkpatrick 94] Kirkpatrick, D. L., Evaluating Training Programs: The Four Levels, Berrett-Koehler, San Francisco, 1994. [Macke 96] Macke, S., Khajnoori, S., Hirmanpour, I., "An Industry/Academic Partnership that Worked: An In-Progress Report", Proceedings of 9th Conference on Software Engineering Education, Daytona Beach, FL, April, 1996. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Next Month's Topic The March 1998 topic will be software education across the computing field. This will be a follow-up to a CSEE&T workshop on the same subject (see related article under CSEE&T 98). Please contact Don Bagert if interested in this topic. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ By: Don Bagert (Academic/Misc Editor) Upcoming topics The May 1998 issue of FASE will be its 100th. The topic for that issue is tentatively titled "FASE: Past and Future". Besides looking at some of the highlights of the first 100 issues of FASE, this article will look at the possibilities and predictions for the future. Also, the past and potential futures of publication in the software engineering education and training field will also be examined. Here are some of the topics planned for future issues: * Distance Learning * Software Engineering Education and Training Outside of the U.S. * Object Technology Education and Training * Software Metrics Education * Web Pages * Student Team Projects * Software Survivability Education Please send any suggestions for future topics to me at bagert@ttu.edu. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ####################################################################### Software Technology Review From: Bob Rosenstein ************************************************** Software Technology Review Do you sit in meetings and wonder what is that new technology that everyone is discussing? Are you sure that the course notes you wrote will be clearly understood by your students? Would you risk recommending a new technology for your department without fully knowing its limitations and alternatives? The SEI Software Technology Review provides you with a primary source of information about software technology. The Software Technology Review is a "Cliffs Notes" like summary of software technology, continuously updated on the World Wide Web. It documents a shared common knowledge base and provides a collection of high-level information that points to in-depth information. Educators find using the Software Technology Review enables them to prepare better presentations and speeches because they have a more complete understanding of software technologies. Students use the Software Technology Review to point to documented experiences of use and as a guide/reference baseline in their writing. The Software Technology Review has been modeled after professional refereed journals (i.e., Communications of the ACM, IEEE Software) with volunteer authors, reviewers, and/or editorial board members. The SEI provides the management/coordination of the Software Technology Review. Organizations contribute to the growth of the Software Technology Review, both in terms of involvement and financial support, because of its relevance to the general software community. The Software Technology Review is available on the SEI Web (http://www.sei.cmu.edu/technology/str). Downloadable PDF and Postscript files are also available through the Web site. For more information about the Software Technology Review Customer Relations Internet Email Software Engineering Institute customer-relations@sei.cmu.edu Carnegie Mellon University Pittsburgh, PA 15213-3890 Phone, Robert Rosenstein Email 412/268-8468 str@sei.cmu.edu FAX World Wide Web 412/268-5758 http://www.sei.cmu.edu/technology/str/ ####################################################################### Journal of Systems and Software - Special Issue From: Hossein Saiedian The upcoming special issue of Journal of Systems and Software (March 1998)...is a special issue on Formal Methods Technology Transfer. Contributors include David Parnas and Michael Jackson. David Parnas talks about the importance of FM education. ####################################################################### PSP Studio at East Tennessee State From: Joel Henry The East Tennessee State University Computer and Information Sciences Department proudly announces the release of PSP Studio, a complete, stand-alone, software product automating the Personal Software Process. PSP Studio is a fully functional software implementation of the PSP through level 3.0. Time logs, Defect Logs, Product Plans and more are automated in this 32 bit, Windows based tool. PSP Studio is distributed free and available from: http://www-cs.etsu.edu/softeng/psp/index.htm Comments or questions can be directed to Dr. Joel Henry, Assistant Professor, East Tennessee State University (henryj@etsu-tn.edu). ####################################################################### Software Process Improvement Text Published From: Dr. Sami Zahran via Laurie Werth Dear SPI Colleagues, The following book has just been published by Addison-Wesley in January 1998: Title: Software Process Improvement: Practical Guidelines for Business Success. ISBN: 0-201-17782-X 448 Pages Hbk Series: Software Engineering Institute SEI Series in Software Engineering Features: Forewords by: Watts Humphrey and Mark Paulk. Contents: Part 1: Process Thinking Part 2: A Framework for Software Process Improvement Part 3: Making Software Process Improvement Happen Part 4: Current Models and Standards of Software Process Improvement (CMM, ISO/IEC 15504, BOOTSTRAP, + Other Initiatives) Part 5: Business Benefits of Software Process Improvement. Comments on the Book: "In addition to talking about process improvement, Sami Zahran provides useful guidance from a practitioner's perspective ... More importantly he discusses the issues which you, the user, will face as you pursue process improvement on your own" Watts Humphrey, Software Engineering Institute " ..Dr. Zahran's book should help the reader understand the trade-offs and issues associated with effective software process improvement" Mark Paulk, Software Engineering Institute " This is exactly the kind of book that is needed to spread the awareness of the potential of Software Process Imporvement and how to succeed in it .... It is to be warmly welcomed and recommended." Colin Tully, Independent Consulting Software Engineer. Dr. Sami Zahran Senior Management Consultant "Louisville" 60 Bathurst Walk, Richings Park, Iver, Buckinghamshire, SLO 9EQ United Kingdom Tel / Fax: +44 (0) 1753 651240 email: sami@cloud9.win-uk.net +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ####################################################################### ASE'98 From: Bashar Nuseibeh Call For Papers 13th IEEE International Conference on Automated Software Engineering - ASE'98 October 13-16, 1998, Honolulu, Hawaii, USA (co-located with WCRE'98) Paper Submission: May 8, 1998 (email abstracts by May 1, 1998) Latest information: http://www.ics.uci.edu/~ase98 The IEEE International Conference on Automated Software Engineering brings together researchers and practitioners to share ideas on the foundations, techniques, tools and applications of automated software engineering technology. Both automatic systems and systems that support and cooperate with people are within the scope of the conference, as are computational models of human software engineering activities. ASE-98 encourages contributions describing basic research, novel applications, and experience reports. The solicited topics include, but are not limited to: * Architecture * Automating software design and synthesis * Automated software specification and analysis * Computer-supported cooperative work, groupware * Domain modeling * Education * Knowledge acquisition * Maintenance and evolution * Process and workflow management * Program understanding * Re-engineering * Requirements engineering * Reuse * Testing * User interfaces and human-computer interaction * Verification and validation The ASE Conference, formerly called the Knowledge-Based Software Engineering Conference, has for the past decade provided a forum for researchers and practitioners to discuss the application of automated reasoning and knowledge representation to software engineering problems. In conjunction with the name change a year ago, the scope of the conference expanded to encourage international participation and to reach other scientific communities concerned with formal methods, partial evaluation, process support, human-computer interface support, requirements engineering, reverse engineering, testing, or verification & validation. All accepted papers will be published in the proceedings. In addition, several of the highest quality papers will be selected for a special issue of The Journal of Automated Software Engineering (Kluwer). ASE-98 will also include invited talks, tutorials, panel discussions, and project demonstrations. Separate calls will appear for participation in some of these activities. SUBMISSION INFORMATION Papers should not exceed 6000 words in length, with full page figures counting as 300 words. Papers will be reviewed by at least three members of the program committee according to: technical quality, originality, clarity, appropriateness to the conference focus, and adequacy of references to related work. Papers that exceed the length restriction will not be reviewed. Application papers and experience reports should clearly identify their novel contributions and lessons learned. Six hardcopies of each submitted paper should be sent (no fax) to Dr. David Redmiles at the address below. The submission deadline is May 8, 1998. A paper's title, authors, and abstract should be emailed by May 1 to ase98@ics.uci.edu. RELATED CONFERENCE Attendees should note that ASE'98 will be co-located and will have overlapping sessions with the 5th Working Conference on Reverse Engineering (WCRE '98). See http://www.reengineer.org/WCRE98/ for more information on WCRE '98. ORGANIZING COMMITTEE General Chair Alex Quilici Department of Electrical Engineering University of Hawaii at Manoa 2504 Dole Street, Honolulu, Hawaii 96822, USA Tel: +1 808 956-9735 Fax: +1 808-956-3427 Email: alex@wiliki.eng.hawaii.edu Program Chairs Bashar Nuseibeh Department of Computing Imperial College London SW7 2BZ, UK Email: ban@doc.ic.ac.uk David Redmiles Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA Tel: +1 714 824-3823 Fax: +1 714 824-1715 Email: ase98@ics.uci.edu Tutorials Chair Scott Henninger, University of Nebraska-Lincoln, USA Email: scotth@cse.unl.edu Doctoral Symposium Chair Steve Easterbrook, NASA/WVU, USA Email: steve@atlantis.ivv.nasa.gov Tool Demonstrations Chair Jeffrey van Baalen, NASA Ames, USA Email: jvb@ptolemy-ethernet.arc.nasa.gov Program Committee Tsuneo Ajisaka, Japan Perry Alexander, USA Daniel Berry, Israel Leopoldo Bertossi, Chile Barry Boehm, USA Ted Biggerstaff, USA Alex Borgida, USA Alan Bundy, UK Shing-chi Cheung, Hong Kong Paul Clements, USA Steve Easterbrook, USA Wolfgang Emmerich, UK Martin Feather, USA Steve Fickas, USA Pierre Flener, Turkey Alfonso Fuggetta, Italy Carlo Ghezzi, Italy Michael Goedicke, Germany Joseph Goguen, USA Cordell Green, USA John Grundy, New Zealand Robert Hall, USA Mehdi Harandi, USA Scott Henninger, USA Stan Jarzabek, Singapore Louis Hoebel, USA Mehdi Jazayeri, Austria Lewis Johnson , USA Richard Jullig, USA Simon Kaplan, Australia Rene Kloesch, Austria Bernd Kraemer, Germany Jeff Kramer, UK Yves Ledru, France Julio Leite, Brazil Mike Lowry, USA Neil Maiden, UK Renaud Marlet, France Ali Mili, USA John Mylopoulos, Canada Klaus Pohl, Germany Christian Rathke, Germany Robert Rist, Australia David Rosenblum, USA Kevin Ryan, Ireland Akiyoshi Sato, Japan Dorothy Setliffe, USA Motoshi Saeki, Japan Howard Schrobe, USA Douglas Smith, USA Alistair Sutcliffe, UK Loren Traveen, USA Enn Tyugu, Sweden Jeffrey van Baalen, USA Axel van Lamsweerde, Belgium Richard Waldinger, USA Jim Welsh, Australia Chris Welty, USA Douglas White, USA David Wile, USA Publicity Chairs Americas: John Penix, USA Asia & Australia: Akiyoshi Sato, Japan Europe & Africa: Rainer Koschke, Germany Registration Chair: Perry Alexander ####################################################################### Conference on Student Projects From: Mike Holcombe The Fund for the Development of Teaching and Learning (FDTL) is a HEFCE-funded programme for encouraging the dissemination of new approaches to the teaching of various subjects in universities. There are 4 funded projects concerned with the teaching of computing and three of these are planning to hold a joint one day conference next Easter in Sheffield (April 8-9th). (I am using this list because I believe that CPHC is interested in being kept informed of developments in these FDTL projects.) Further details are on URL < Dear colleague, This is to request a moment of your time to assist in providing data for a conference paper. The paper analyzes some reasons why projects fail (cancelled, or go over buget and schedule). Would you please show if you agree or disagree with the following reasons for project failure? Just write an "A" or a "D" in the appropriate column below agree/disagree. If you have no opinion on the reason, please leave it blank. I will send all respondents a copy of the final paper. The paper will be send to the E-mail address originating your response Agree/Disagree Reason Poor requirements Failure to use experienced people Failure to use Independent Verification and Validation (IV&V) Lack of process and Standards Lack of, or, poor plans Failure to validate original specification and requirements Lack of Configuration Management Low morale Management does not understand SDLC Management that does not understand technical issues No single person accountable/responsible for project Client and development staff fail to attend scheduled meetings Coding from high level requirements without design Documentation is not produced Failure to collect performance and process metrics and report them to management Failure to communicate with the customer Failure to consider existing relationships when replacing systems Failure to reuse code Failure to stress test the software Failure to use problem language High staff turnover Key activities are discontinued Lack of Requirements Traceability Matrix Lack of clearly defined organizational (responsibility and accountability) structure Lack of management support Lack of priorities Lack of understanding that demo software is only good for demos Management expects a CASE Tool to be a silver bullet Political considerations outweigh technical factors Resources are not allocated well The Quality Assurance Team is not responsible for the quality of the software There are too many people working on the project Unrealistic deadlines - hence schedule slips Hostility between developer and IV&V Other (please write in here) Now please tell me about yourself management __ years of experience ____ non-management __ years of experience ___ Background systems engineering __ software engineering __ hardware engineering __ Please identify up to seven items in the list which you feel are the most important and list them in in order of priority. Note 1 is the item with highest priority, 7 is the item with the lowest priority. Please list them below, or write the number next to the appropriate item in the above list 1 2 3 4 5 6 7 Thankyou for your time Joe Kasser PS. If you know of any distribution lists on the topics of software engineering, systems engineering and project management, please forward this survey questionaire appropriately. ####################################################################### DEXA '98 International Workshop on Large-Scale Software Composition From: Rudolf K. Keller International Workshop on Large-Scale Software Composition held in conjunction with the 9th International Conference on Database and Expert Systems Applications (DEXA'98) Vienna, Austria, August 24-28, 1998 (one-day workshop) http://www.iro.umontreal.ca/~keller/Workshops/DEXA98 *** Submission Deadline: March 31 1998 *** **Workshop proceedings to be published by IEEE Computer Society Press** Background Large organizations throughout industry face immense problems when they have to adapt their acquired software systems with millions of lines of code to rapidly changing requirements. Far too often, such systems have evolved from an uncoordinated build-and-fix attitude towards software development and suffer from a lack of methodical support during maintenance. The original design intents of the software systems are obfuscated, or worse, have disappeared altogether. It takes immense effort to implement and test changes as the effects on other software modules and the impact on future reuse are hard to predict. Component-based software development (CBSD) proclaims to address these difficulties of software evolution. CBSD stands for software construction by assembly of prefabricated, configurable, and independently evolving building blocks. The idea is to assemble software by letting off-the-shelf components communicate with each other. CBSD has gained momentum with the proliferation of programming environments based on Microsoft's Component Object Model (COM) or Sun's JavaBeans. Yet, reality shows that CBSD has proven mainly effective for systems implementation in well-understood application domains, such as graphic user interfaces, but is still insufficient for the creation of reusable and changeable architectures of large-scale software, such as telephone switches. Workshop Goals and Format We seek participants to cover practical and theoretical issues of software composition, addressing three key questions. * What are the components of large-scale software systems? * How can we effectively manage components in repositories? * How can we achieve assembly of large-scale software systems out of components? The workshop will comprise an initial keynote address, followed by two or three sessions. Each session will address a specific theme, which will be introduced by a number of relevant issues and questions. Then, the session papers will be presented, and each session will conclude with a short plenary discussion. Workshop Themes Theme topics include the following, as they help resolve above key questions. 1. Setting the stage. o Needs of the architects of large-scale software systems. o Types and characteristics of components in large-scale software. o State of practice in industrial use of software components and software architectures. 2. Designing large-scale, component-based software. o Software and design composition techniques. o Relationship between components and frameworks, patterns, protocols, etc. o Legacy code in a component-based software development environment. o Tool support for component-based software development - what's hot, what's not? 3. Managing components in repositories. o Repository tools. o Retrieval techniques. o Schemas and artifacts.. 4. Introducing and managing component-based software development. o Transition into component-based software development. o Component-based development process. 5. Assessing large-scale, component-based software. o Measurement and empirical studies on the relationship between component based development and the -ilities of software quality (reusability, changeability, reliability, evolvability, etc.). o Cost and benefits analysis of the component-based approach. o Validation and verification of component-based applications. 6. Looking ahead. o Where do we want to go? o Where shouldn't we go? o Where do we go? Important Dates * Submission deadline: March 31, 1998 * Notification of acceptance: April 30, 1998 * Camera ready copies: June 5, 1998 Submission Details Authors are invited to submit research contributions representing original, unpublished work. Submissions may be theoretical or practical in nature (research papers, empirical studies, experience reports, etc.) and can be either full papers (max. 10 pages in the proceedings format) or short papers (max. 5 pages in the proceedings format). All papers will be refereed by at least 2 members of the workshop program committee. Evaluation will be based on originality, significance, technical soundness, and clarity of exposition. All accepted papers will be published by the IEEE Computer Society Press in as proceedings of the DEXA'98 workshops. Papers must be written in English. All submitted papers must be formatted according to the author guidelines provided by the IEEE Computer Society Press. These guidelines are available at http://computer.org/cspress/instruct.htm. Please submit your paper electronically by e-mail. If you cannot send an electronic copy of your paper, ONLY THEN submit hardcopies of your paper. In either case (electronic or hard copy submission) please also send an e-mail in ASCII format (no markup languages, no binhex, no binary files) including the paper title, abstract, keywords, author names, addresses, and affiliations. Electronic Submission Please submit your paper electronically by e-mail to Ruedi Keller (keller@iro.umontreal.ca). Please prepare your paper as plain ASCII PostScript only, with NO encoding, condensing, or encapsulation. Guidelines for generating and submitting PostScript files are available at http://computer.org/author/psguide.htm. Hard Copy Submission Please send four hard copies to the address below. Rudolf K. Keller Université de Montréal Dépt. IRO (informatique et recherche opérationnelle) C.P. 6128, succursale Centre-ville Montreal (Quebec) H3C 3J7, CANADA Program Committee Israel Z. Ben-Shaul, Technion, Haifa, Israel Ritu Chadha, Bellcore, Morristown, NJ, USA Gang Chen, Southeast University, Nanjing, P. R. of China Premkumar Devanbu, University of California at Davis, USA Patrick J. Finnigan, IBM SWS Toronto Lab, Toronto, Canada Volker Gruhn, University of Dortmund, Germany Rudolf K. Keller (Chair), University of Montreal, Canada Stuart Kent, University of Brighton, UK Bruno Laguë, Bell Canada, Montreal, Canada Kai-Uwe Mätzel, Ubilab, Zürich, Switzerland Peter Mössenböck, University of Linz, Austria Mauro Pezzè, Politecnico di Milano, Italy David Rosenblum, University of California at Irvine, USA Reinhard Schauer, University of Montreal, Canada Scott Tilley, SEI, CMU, Pittsburgh, PA, USA Andreas Vogel, Visigenic, San Mateo, CA, USA Workshop Organizers Rudolf K. Keller University of Montreal, Montreal, Canada E-mail: keller@iro.umontreal.ca WWW: http://www.iro.umontreal.ca/~keller Bruno Laguë Bell Canada, Montreal, Canada E-mail: bruno.lague@bell.ca WWW: http://www.bell.ca Reinhard Schauer University of Montreal, Montreal, Canada E-mail: schauer@iro.umontreal.ca WWW: http://www.iro.umontreal.ca/~schauer Please address questions and submissions to Ruedi Keller. Workshop Sponsors * DEXA'98 (9th Intl. Conf. on Database and Expert Systems Applications) * Bell Canada * CSER (Canadian Consoritum for Software Engineering Research) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Conference Announcements ####################################################################### CSEE&T BOF on Education Journal From: Jorge L. Diaz-Herrera Hello everyone. I would like to invite you all to a BoF that we are organizing to discuss the issue of the journal on se/computing/software education. I am suggesting that this take place on Wed night Feb 25 hoping for our colleagues from SIGCSE attendance. [Editor's Note: As far as I know, there will be a meeting on Wednesday night at the Marriott Marquis. Please contact Jorge for details.] Although technically CSEE&T would have finished by then (?) I do not think this would be a problem, would it Mike(s)? [Editor's Note: Jorge is referring to Mike McCracken and Mike Lutz, who are the Conference Chair and Program Chair, respectively, of CSEE&T 98.] Also, I have created a list server account for this group. Please subscribe by simply sending this message TO: seed@starbase.monmouth.edu SUBJECT: CC: subscribe seed Make sure you send this message from the account you read mail from. I look forward to seeing you all in Atlanta, best regards jorge --..-- Prof. Jorge L. Diaz-Herrera (Visiting Scientist, Software Engineering Institute, Carnegie Mellon U) Chair, Software Engineering Department Monmouth University West Long Branch, NJ 07764-1898 (732) 571-7501 (Sec) (732) 263-5253 (Fax) http://starbase.monmouth.edu/~jdiaz/ ####################################################################### Summer School on Reliability and Safety of Human-Machine Systems From: Virginia Bocci via Laurie Werth Call for Participation to the European Summer School on RELIABILITY AND SAFETY OF HUMAN-MACHINE SYSTEMS September 6 - 13, 1998 - Knossos Royal Village, Crete AIM: There is an increasing use of automation in contexts where humans and machines interact in process control, transportation, medical systems and many other fields. The dependability analysis and evaluation of these systems requires an integrated approach, considering the hardware, software and human components and their interactions. Aim of the summer school is to help researchers and practitioners in developing the interdisciplinary competencies that are needed for the design, analysis and evaluation of human-machine systems. Lecturers will be expert senior researchers from the different disciplines concerned (human reliability and cognitive science, hardware and software dependability). They will introduce common goals, needs and problems of the different disciplines, and will describe the existing methods for quantitative and qualitative analysis and evaluation of human-machine systems. Practical work groups on case studies, will help young students to link those information across discipline boundaries. ORGANISED BY: The OLOS research network of the European Human Capital and Mobility Programme, in co-operation with the University of Siena, supported by the European Community - DGXII TMR Programme, and with the sponsorship of: European Safety and Reliability Association (ESRA), European Association for Cognitive Ergonomics (EACE), European Network of Clubs for Reliability and Safety of Software (ENCRESS), Foundation for Research and Technology Hellas, Alenia, ENEA. ATTENDANCE: The summer school is open to researchers and practitioners at post-graduate level (or equivalent) or post-doctoral level, with background in at least one of the discipline concerned with analysis and evaluation of human-machine systems: software and systems reliability engineering and safety, all the aspects of hardware reliability, all the aspects of human reliability and cognitive science. FEES AND ACCOMMODATION COSTS: Advance Registration. (until April 15): 680.000 It. Lit. (350 ECU) Late Registration (after April 15): 1.070.000 It. L. (550 ECU) Accommodation: 130.900 GRD (450 ECU) REGISTRATION AND GRANTS: Registration will be limited to the first 60 students. After June 30, 1998 registrations will not be guaranteed and will depend on accommodation availability. Registration fees include courses and textbook. School will be residential, the accommodation fees are for full board in double rooms. A limited number of single rooms are available at an additional cost of 38.500 GRD (130 ECU). To register fill in the attached registration form, and send it to the contact address with a CV and with a check for the appropriate registration fees, payable to: "Magnifico Rettore dell'Universita' di Siena" or make a bank payment to "Banca Monte dei Paschi di Siena SpA - CC: 50400.66 - ABI: 1030.6 - CAB: 14200.0 BIC: pascitmmsie" specifying that payment is a "Registration fee for Reliability and Safety Summer School". Accommodation fees will be paid on site at arrival. All payments must be in local currency (Italian Lira for the registration and Greek Drachma for the accommodation). REGISTRATION REQUIRE THE PAYMENT OF THE DUE REGISTRATION FEES, NO REGISTRATION FORM WILL BE PROCESSED TILL WHEN THE CORRESPONDING PAYMENT IS RECEIVED. Thanks to the support of the European Community and some of the sponsors, grants will be available for European advanced students, young researchers, members of sponsor organisations, and participant from Less Favoured Regions (Regions defined by the European Community as Objective 1 and 6). Grants will cover up to the full cost of accommodation, travel and 60% of the registration fees. Applications for grants should be sent by March 31, 1998. To apply fill in the attached registration form and send it to the contact address with a CV and a motivation letter. Decisions on grants will be returned to applicants by April 30, 1998. Applicants selected for grants will be required to pay a reduced registration fee of 300.000 It. Lit. (150 ECU) by May 31, 1998. Applicants not selected, will have the advance registration period extended to May 31, 1998. PROGRAM: -) Introduction to the evaluation of human-machine systems through real examples and case studies; -)Background and introduction to: cognitive psychology, interaction design, evaluation of dependability and performances, fault tolerance, life cycle of systems, standards; -) Methods for qualitative and quantitative analysis of human-machine systems; -) Description of real human-machine systems used in industrial environments and of problems experienced in designing, assessing and using these systems; -) Practical lessons and workgroups for the analysis and evaluation of existing systems. The closed environment will ensure the appropriate setting to allow for informal contacts and discussions between participants and training staff during and after the lessons. SPEAKERS AND ORGANISERS: S. Anderson - Univ. of Edinburgh (UK) A. Bertolino - IEI CNR (I) B. Ciciani - Univ. of Rome I (I) D. Embrey - HRA (UK) G. Gloe - TUV (D) W. Goerke - Univ. of Karlsruhe (D) M. Kaaniche - LAAS CNRS (F) K. Kanoun - LAAS CNRS (F) J. C. Laprie - LAAS CNRS (F) B. Littlewood - CSR (UK) C. Mazet - LAAS CNRS (F) A. Pasquini - ENEA (I) - Scientific resp. A. Rizzo - U. of Siena (I) - Administrative resp. G. Sonneck - ARCS (A) L. Strigini - CSR (UK) G. van der Veer - Vrije Univ. (NL) CONTACT ADDRESS: Reliability and Safety Summer School Virginia Bocci Laboratorio Multimediale, University of Siena Via del Giglio, 14 53100 Siena, ITALY Email: school@media.unisi.it Fax: +39 577 298461 http://www.media.unisi.it/school =================== APPLICATION FORM =================== Name: .................................................... Surname: ................................................. Complete Address: ........................................ .......................................................... Legal residence: ......................................... .......................................................... Age: ........Nationality: ................................ Telephone: ............................................... Fax: ..................................................... E-Mail: .................................................. Affiliation:.............................................. ...I want to register and attach a check (or made a bank payment) of 680.000 It. Lit. (till April 15) ...I want to register and attach a check (or made a bank payment) of 1.070.000 It. Lit. (after April 15) ...I wish to apply for a grant ...I want to reserve a single room +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Faculty Positions ####################################################################### Texas Tech University Chair Department of Computer Science Applications are invited for Chair of the Department of Computer Science at Texas Tech University, with a start date of September 1, 1998 or January 1, 1999 at the latest. The department is strongly committed to being a nationally recognized program within the computing field. Applicants should demonstrate leadership, motivational skills, communication and teaching abilities, and a strong record of publications and funded research. The record of accomplishments should be commensurate with appointment at the rank of full professor with tenure. An applicant must be either a citizen or a permanent resident of the U.S. The Department of Computer Science is within the College of Engineering, and offers B.S., M.S., and Ph.D. degrees. The department participates in both an EE/CS dual degree program and a Computer Engineering program in conjunction with the Department of Electrical Engineering, as well as dual degrees with both Chemical Engineering and Mathematics. At present, there are over 500 undergraduate and 80 graduate students in computer science degree programs. The graduate program offers specialties in computer engineering, software engineering, and intelligent systems. Faculty perform scholarly and funded research in many areas, including: distributed computing and modeling; graphics and haptics; high performance computing; multimedia systems; neural networks; real-time systems; software development environments; and software metrics. Information about the department, college, university, and the City of Lubbock may be found at www.cs.ttu.edu/ChairSearch/. Applicants should send a letter expressing interest in the position, a detailed resume, and the names and addresses of three professional references to: Chairperson, CS Search Committee, Department of Computer Science, PO Box 43104, Texas Tech University, Lubbock TX 79409-3104. All questions should be directed to ChairSearch@cs.ttu.edu. Applications will be reviewed as they are received, until the position is filled. Texas Tech University is an Equal Opportunity, Affirmative Action Employer. ####################################################################### From: Iraj Hirmanpour via Tom Hilburn ==================================================== Computer Science Department Embry-Riddle Aeronautical University ==================================================== Computer Science/Engineering Faculty Positions **************************************************** Applications are invited for faculty positions in the Department of Computer Science, Embry-Riddle Aeronautical University, Daytona Beach, Florida. Appointments are available for both tenure track and non-tenure track faculty beginning in the fall of 1998. The tenure track positions are teaching/research and require a Ph.D. in Computer Engineering/ Science or closely related field. The non-tenure track positions are primarily teaching positions, require as a minimum a Masters degree in a computing discipline and significant industry experience. For additional information and application specifics, see http://www.erau.db.erau.edu. Embry-Riddle is an equal opportunity/affirmative action employer. **************************************************** ####################################################################### From: Eric Dubois The University of Namur, Belgium Department of Computer Science JOB OPENINGS The Department of Computer Science invites applications for two faculty positions. -------------------------------------------- Assistant professor (50%) in Programming and Elementary Computer Science (M/F) -------------------------------------------- - Degree required: Ph. D. in Computer Science, or Ph. D. in Applied Sciences, or Ph. D. in Engineering, or equivalent academic curriculum; - Teaching duties: Introduction to Computer Science, to the main concepts of programming and of information systems development. Tutoring of undergraduate students, supervision of theses by graduate and post-graduate students. - Research duties: according to the applicant's project, research could be conducted either in the field of teaching methods for computer science (teaching methods relative to education or to professional development situations), or in any field of programming in relation to current trends in information systems, such as the design of distributed systems and programming methods related to emerging technologies (JAVA, CORBA, etc.); - Applications must be received by March 31, 1998. ---------------------------------------------------- Assistant professor (100%) in Telecommunications and Distributed Information Systems (M/F) ---------------------------------------------------- - Degree required: Ph. D. in Computer Science, or Ph. D. in Applied Sciences, or Ph. D. in Engineering, or equivalent academic curriculum; - Teaching duties: Teleinformatics (functions and boundaries of telecommunications; ISO and DOD models; elementary concepts in protocols, services and standards of physical and logical layers; network technologies; application of stochastic processes to networks; principles for the design of distributed information systems; etc.). Tutoring of undergraduate students, supervision of theses by graduate and post-graduate students. - Research duties: Research should be conducted, on the one hand, in high-level technology assessment of all ISO layers (and, particularly, of functions and boundaries of new techniques) and, on the other hand, in topics such as distributed objects, methodology and realization of design tools for teleinformatics solutions, assessment of performance and costs of teleinformatics solutions, etc. - Applications must be received by March 31, 1998. Further Information - Please contact Prof. Claire Lobet-Maris, Institut d'Informatique, Facultés Universitaires Notre-Dame de la Paix 21 rue Grandgagnage B-5000 NAMUR (BELGIUM) Fax 32-81-72 49 67 E-Mail clobet@info.fundp.ac.be ####################################################################### The University of Hawaii at Hilo (visiting) From: Judith Gersting ============== VISITING FACULTY POSITION IN HAWAII The Computer Science Department at the University of Hawaii at Hilo has an opening for a visiting faculty member for the academic year beginning August, 1998. Teaching load includes a one-year, project-driven software engineering course, plus other undergraduate computer science courses. The University of Hawaii at Hilo is a small (2500 students) state-supported undergraduate institution located on the Big Island of Hawaii, a setting noted for its spectacular diversity of both geography and population. The department offers a B.S. in Computer Science within a liberal arts setting. Computing facilities include laboratories with networked NT workstations and NT and UNIX servers. For further information, please contact Dr. Judith Gersting, Chair, Computer Science Department, University of Hawaii at Hilo at gersting@Hawaii.edu. The University of Hawaii at Hilo is an equal opportunity/affirmative action employer. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE The Forum for Advancing Software engineering Education (FASE) is published on the 15th of each month by the FASE editorial board. Send newsletter articles to one of the editors, preferably by category: Articles pertinent to corporate and government training to Kathy Beckman ; Academic education, and all other categories to Don Bagert . Items must be submitted by the 8th of the month in order to be considered for inclusion in that month's issue. Also, please see the submission guidelines immediately below. FASE submission format guidelines: All submissions must be in ASCII format, and contain no more than 71 characters per line (72 including the new line character). This 71-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. Everyone that is receiving this is on the FASE mailing list. If you wish to leave this list, write to and, in the text of your message (not the subject line), write: signoff fase To rejoin (or have someone else join) the FASE mailing list, write to and, in the text of your message (not the subject line), write: subscribe fase But what if you have something that you want share with everyone else, before the next issue? For more real-time discussion, there is the FASE-TALK discussion list. It is our hope that it will be to FASE readers what the SIGCSE.members listserv is to that group. (For those of you that don't know, SIGCSE is the ACM Special Interest Group on Computer Science Education.) To subscribe to the FASE-TALK list, write to and, in the text of your message (not the subject line), write: subscribe fase-talk Please try to limit FASE-TALK to discussion items related to software engineering education and training; CFPs and other such items can still be submitted to the editor for inclusion into FASE. Anyone that belongs to the FASE-TALK mailing list can post to it. As always, there is no cost for subscribing to either FASE or FASE-TALK! Send requests for information problem reports, returned mail, or other correspondence about this newsletter to . If it is a LOC (letter of comment) that can be included as such in a future issue of FASE, please put "letter of comment" (without the quotes) as the subject. Back issues (from 1997) can be found on the FASE web page . The FASE Staff: Don Bagert -- Academic/Misc Editor and ListMaster Dept. of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: bagert@ttu.edu Kathy Beckman -- Corporate/Government Editor Computer Data Systems One Curie Ct. Rockville MD 20850 USA Phone: 301-921-7027 Fax: 301-921-1004 Email: Kathy.Beckman@cdsi.com Laurie Werth -- Advisory Committee Taylor Hall 2.124 University of Texas at Austin Austin TX 78712 USA Phone: 512-471-9535 Fax: 512-471-8885 Email: lwerth@cs.utexas.edu Nancy Mead -- Advisory Committee Software Engineering Institute 5000 Forbes Ave. Pittsburgh, PA 15213 USA Phone: 412-268-5756 Fax: 412-268-5758 Email: nrm@sei.cmu.edu