Forum for Advancing Software engineering Education (FASE) Volume 11 Number 03 (134th Issue) - March 15, 2001 Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Call for Articles, Topics and Guest Editors Upcoming Topics Teaching a Software Engineering Project Course Software Engineering as a Profession in the United Kingdom Articles Innovative Software Engineering Education by Lawrence Bernstein and David Klappholz Better Software Engineering through Mathematics Education by Rex Page Society to Offer Software Engineering Professional Certification by Mary-Louise Piner News Items Software PEs Work on Questions for Revised NCEES Licensing Exam Countries with Subscribers to FASE Calls for Participation ITiCSE Working Group for Instructors of Capstone Courses HICSS Minitrack on Advances in Software Specification and Verification Advance Programs PSP(SM) and TSP(SM) 2001 Summer Faculty Workshops Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: The FASE Staff Call for Articles, Topics and Guest Editors The FASE staff is always interested in articles or topic suggestions in the areas of software engineering education, training and professional issues. You may suggest yourself as a guest editor for a particular topic. Send articles or topic suggestions to one of the editors, preferably by category: Articles pertinent to academic education to Tom Hilburn ; corporate and government training to David Carter ; professional issues and all other categories to Don Bagert . FASE submission format guidelines: All submissions must be in ASCII format, and contain no more than 70 characters per line (71 including the new line character). This 70-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. All characters (outside of the newline) should in the ASCII code range from 32 to 126 (i.e. "printable" in DOS text mode). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Upcoming Topics ###################################################################### Call for Contributions for an upcoming monthly topic: TEACHING A SOFTWARE ENGINEERING PROJECT COURSE In recent years, project courses have become common at universities world-wide, in addition to industrial attachments. The objective of this special issue is to share experiences with teaching a project course, in areas such as: - skills training, - approaches to teaching a project course, - what works and what does not work, - problems in teaching a project course and solutions (e.g., high workload, lack of skilled supervisors, etc.) - the impact of the project course on the market value of graduates. We seek contributions from colleagues involved in teaching project courses. Send 1/2 - 2 pages describing your approach and experiences. We suggest that you take a look at the August 1999 issue of FASE (http://www.cs.ttu.edu/fase/v9n08.txt) that also dealt with project courses. We are looking for new approaches or new variations on old approaches. PLEASE SEND YOUR SUBMISSIONS TO: Stan Jarzabek Department of Computer Science, School of Computing National University of Singapore Singapore 117543 e-mail: stan@comp.nus.edu.sg WWW: http://www.comp.nus.edu.sg/~stan/ fax: 65-779-4580; tel: 65-874-2863 SUBMISSION GUIDELINES: On the front page, please write the following summary (If you do not have time to write a short paper, submit only the summary): Author: Institution: The type of your project course: 1. Industry involvement: yes no 2. Projects proposed and supervised by faculty members in areas of their expertise. 3. Project(s) formulated and conducted by a small number of faculty members specializing in Software Engineering, with faculty members and teaching assistants supervising student teams. 4. Other: please describe The project course is taught at: 1. undergraduate level 2. graduate level The objectives of your project course (add to or delete from the list below): 1. degree accreditation concerns 2. professional licensing concerns 3. better prepare students for industrial projects, 4. develop ability to work in a team, 5. enhance communication skills and writing skills, 6. enhance project planning skills, 7. other objectives - please describe. Your project course is offered in the: 1. general Computer Science degree 2. Software Engineering degree 3. other - please indicate. Indicate project workload: 1. project is a part of a general Software Engineering course 2. full-fledged project course with workload equivalent to: for example, a typical 1 term course (13 weeks, 3 lectures per week) Rate the impact of the project course on the market value of your graduates: 1 - low 5 - very high Submissions should be sent by e-mail in PDF or ASCII to: stan@comp.nus.edu.sg ###################################################################### Software Engineering as a Profession in the United Kingdom Guest Editors for this Upcoming Topic: Barrie Thompson and Helen Edwards University of Sunderland barrie.thompson@sunderland.ac.uk, helen.edwards@sunderland.ac.uk For more information on this topic, please contact the guest editors. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Articles ###################################################################### By: Lawrence Bernstein and David Klappholz Innovative Software Engineering Education Professors Lawrence Bernstein and David Klappholz Stevens Institute of Technology, Hoboken, NJ Software projects often fail because the staff lacks Software Engineering education or when they had it they fought it. To compound the problem they don't accept Software Best Practices. Our challenge is to overcome the natural biases of software professionals and computer science students. Reading case histories of failed software tends to convince some students of others' stupidity. While other students intellectually accept the existence of the problems, just reading about them does not convert many at the 'gut level.' At the gut level one sits up, takes notice, and does something different. Motivation Our approach is to force students to live through specific case histories, each one chosen to get across a small number of important issues. The method works. Students internalize the software engineering lessons and follow best practices to avoid the traps they experienced. Here is how the approach works. First, a set of software process issues is selected. Here are the ones we chose for our first live-thru case history: 1. the need to have close customer/user relations 2. the need for up-to-date documentation throughout the life of the project 3. the need to identify risks and to develop contingency plans 4. the need to account for human foibles Second, a case history based on a project facing these challenges is chosen. Students are not given the entire case history up front; rather, they are given the same problem/project as the actual developers who executed the case history faced. They are given no more information about the problem/project than were those developers. The project information is simplified to ease understanding. Background Computer Science is the study of the technology (State-of- the-Art) involved in the development of computer software. As it is usually taught in a post-secondary setting, Computer Science deals with "programming in the small," i.e., one-person or few-person software projects. Software Engineering, on the other hand, is the study of the method or process (State-of- the-Practice) whereby production software is developed -- "programming in the large." State-of-the- Practice includes both engineering practices and project management or group dynamic processes. Many post-secondary programs in Computer Science offer a Software Engineering or Senior Project course as a capstone. Because of the very different natures of technology on the one hand and method/process on the other, and because computer science students are typically technology-oriented and method/process-averse, the typical Software Engineering course reaches far fewer future software developers than suits the best interests of either the students themselves or the software industry at large. We have developed a novel instructional method, the Live-Thru Case History method for addressing this problem, have developed a first live-thru case history, and have used it successfully in the first few weeks of a two-semester undergraduate Software Engineering course. The result was that students were shocked into an awareness of the issues and how to deal with them in six weeks of two classes meetings a week. One class meeting was devoted to project meetings and the other to lectures on Software Engineering topics including other case histories. Conducting the Case History Because there would be only one live-thru case history in our Senior Project course, we had to choose one that would achieve the greatest effect in the limited time available. We chose the case history of a brief development project that one of the authors worked on, in 1985, as a public service project. The problem/project was that of automating an elementary school library's manual system for generating overdue-book notices. The class of forty students was divided randomly into four equal-size development teams. Students were given the same details, as were the original software developers in the case history. The instructor played the role of the customer, the school librarian, and was available to students, to respond to questions, both in class and by e-mail. Students were told that the customer would evaluate their work, exactly as work is evaluated in the real world. Results As is frequently the case in real software development projects, the overdue book notice project had a hidden requirement that was so obvious to the customer that she failed to mention it; it is that overdue notices must be sorted, first by teacher name, then, for each teacher by class, and, finally, within each class by student's family name. The system analyst rejected the real software system when she first saw it. The original developers failed to elicit the hidden make-or-break requirement, and thus failed to satisfy it. Each of the student teams fell into this same trap and they learned the lesson of the need to find any 'hidden requirements.' The need for high-quality documentation and for contingency planning were motivated for students by the classroom equivalent of the real-world phenomenon of loss of staff members due to illness, death, relocation, etc. At the midpoint of the project, the student from each team judged, by the instructor, to be the team's strongest developer and another, randomly chosen, team member were removed from the team and re-assigned to a different team. To evaluate the success of the staff change on students' approach to software engineering, after the case study project students were then asked to describe what they would have done differently had they understood that the real-world conditions under which they would be operating included the possibility of staff changes. About three quarters of the students mentioned the importance of up-to-date documentation, and about twenty percent had developed insight into appropriate utilization of staff, including the use of "understudies" and of preparation for the incorporation of new team members and thus demonstrated that they had learned the value of these processes. Evaluation of how well the students internalized the need for solid requirements engineering was done the end of the live-thru case history. A written exam was based on another case history. This case history included a more difficult requirements engineering problem than that of the overdue book notice project. About three quarters of the students showed that they had mastered the notion of hidden requirements, and about one third showed that they had achieved reasonable competence in requirements engineering; about ten percent showed extremely keen insight into the problem. Claims The innovative process of live-through case histories is more effective than the traditional teaching of the Software Engineering course. In the past students were given lectures, homework and exams based on a well-respected Software Engineering text. Then they were asked to develop a project. When they approached the project they could not readily apply the techniques they learned. Once they understood the need for the processes they re-learned them as they tried to apply them. Directions The authors are asking those teaching software engineering to use these case histories in their courses and report on the results. Materials are available at web site www.NJCSE.org along with a complete paper describing the live-thru approach in detail. Please participate in gathering data to support or refute the claims in this paper. It is our intent to use the experience of instructors in several venues to make anecdotal conclusions more meaningful and perhaps statistically significant. We invite those who agree with us to join a consortium for the purpose of creating additional case histories and helping to refine the process. The authors may be reached at lbernstein@ieee.org and d.klappholz@worldnet.att.net. ###################################################################### By: Rex Page Better Software Engineering through Mathematics Education www.cs.ou.edu/research/beseme.shtml Rex Page University of Oklahoma Computing education programs that include a discrete mathematics course have an opportunity to introduce students to the practice of reasoning about software. Many programs miss this opportunity, preferring traditional mathematical examples (number theory is a common choice) to illustrate concepts of set theory, mathematical logic, methods of proof, and the like. Software-based examples can illustrate these concepts at least as well and can provide additional benefits. The notion that reasoning, argumentation, and methods of mathematical proof can help reduce defect rates in software comes as a revelation to many students. Most people doing software development (both students or professionals) labor under the impression that the test-and-debug cycle is the only way to produce software products. Most software engineering experiments focusing on defect rates have found that direct reviews of software reduce defect rates more efficiently than observing erroneous software behavior and attempting to ferret out causes. If reasoned review is effective, it seems prudent to include such practices in the education of future software engineers. Probably the practice of reasoning about software should be included at many points in the curriculum, but curriculum committees often have difficulty agreeing on course content, especially in core courses. Discrete math courses, since they typically include a substantial amount of mathematical logic, methods of proof, and other related topics, automatically provide a vehicle for giving students experience with an effective alternative to test-and-debug. Since the new approach affects only the examples and not the topics or concepts of the discrete math course, individual instructors can often decide on their own, without consulting the entire faculty, to include such material in their discrete math courses. For this reason, the discrete math component in a computing curriculum provides a convenient, non-controversial opportunity to add a valuable element to software engineering education. The Beseme project has delivered a set of materials that discrete math instructors may use to supplement their course offerings. The materials include about 300 slides (partitioned into 29 lectures), homework and reading assignments, examinations, and proof-checking tools. All materials are available through the project website: http://www.cs.ou.edu/research/beseme.shtml The project, which is supported in part by the Information Technology Research Program of the National Science Foundation, includes an ongoing assessment of the effects, on the software development skills of students, of a software-reasoning focus in discrete math. The website will report the results of the assessment as they become available over the three-year span of the project. An assessment based in the initial offering of the material will appear this summer, but the course materials are available now. Discrete math instructors who review the materials and desire assistance in using them are encouraged to contact the project through its website. The project staff is committed to supporting the materials and will appreciate all forms of feedback. ###################################################################### By: Mary-Louise Piner, IEEE Computer Society Society to Offer Software Engineering Professional Certification ******** Beta test participants are still being recruited. If you are interested in participating, contact Stacy Saul at ssaul@computer.org. ******** Software engineers will soon have the opportunity to obtain certification from a respected leader in the computing field. The IEEE Computer Society has worked over the course of several years to develop the Certified Software Engineering Professional program, a credential that will recognize the comprehensive set of skills needed by a professional software engineer. An objective, standards-based credential, the CSEP will cover the breadth of topic areas important to software engineers rather than focusing on narrow tool-specific skills recognized by vendor-sponsored certification programs. The CSEP is not a license, but a peer recognition certification designed to measure an individual's mastery of the fundamental knowledge required to perform the functions of a software engineer. Candidates for the CSEP must meet stringent eligibility requirements to sit for the exam. Preparation courses and materials will be available to eligible candidates, who then must pass a 180-item test. BROAD KNOWLEDGE BASE Because software engineers must demonstrate expertise in a number of skill sets, the CSEP test covers a variety of knowledge areas. These include software configuration management, construction, design, testing, maintenance, and quality; software engineering tools, methods, processes, and management; software requirements engineering; and professionalism and engineering economics. A job analysis study identified the choices of topic areas and exam items. Candidate requirements Candidates applying for CSEP certification must satisfy a number of educational and experience- related requirements. An eligible candidate must hold a bachelor's or equivalent degree and must have had at least two years of software engineering experience within the four-year period prior to the application. In total, the candidate must have had a minimum of 9,000 hours of software engineering experience in at least six of the test's knowledge areas. Candidates must provide evidence of their schooling and experience by providing a current resume, a school transcript, and completed reports of education and experience. In addition, candidates must demonstrate their commitment to professionalism in software engineering by providing either endorsement from two members of the Computer Society, evidence of registration as a professional engineer, or proof of membership in the Computer Society or an equivalent professional society. Test specifics The first CSEP exams will be administered later this year at sites across the United States and Canada and in select cities in Brazil, China, Hungary, India, Ireland, Japan and Russia. Prometric, a provider of technology-based testing services around the world, will host the exam in authorized Prometric Testing Centers. The 180 multiple-choice test questions are based on concepts familiar to software engineering professionals with six or more years of experience. Candidates will have three and one-half hours to complete the test. Candidates who pass the exam will be considered IEEE Computer Society Certified Software Engineering Professionals [see Editor's Note below] for three years following the exam date. To retain the credential thereafter, the certified engineers must participate in continuing education programs to qualify for recertification. This continuing education component ensures that software engineers bridge the gap between the skills obtained through traditional education and changing market needs. FIRST OPPORTUNITY FOR CERTIFICATION COMING SOON A select group of software engineers will soon participate in the beta test of the CSEP exam. In exchange for helping to validate the test, these individuals will have the opportunity to be the first to achieve the Certified Software Engineering Professional designation. Plans are also under way for conducting the first complete CSEP exam. The Society will soon offer the first three-day training sessions to help candidates prepare for the CSEP test. Salary surveys by independent organizations measure the power of certification. For example, the American Society for Quality reports that Certified Software Quality Engineers earn more than their noncertified counterparts. In addition, certification can open the door to better job opportunities, enhanced skills, and increased customer confidence in an engineer's abilities. To find out how you can become an IEEE Computer Society Certified Software Engineering Professional, visit http://computer.org/certification/. Reprinted by permission from Computer vol. 34 no. 3 pg 82. Copyright 2001 by the Institute of Electrical and Electronics Engineers, Inc. [Editor's Note: At the time of publication, exact title of the certification that would be obtained through the CSEP examination was yet to be finalized. FASE will provide that information when it is available.] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### Software PEs Work on Questions for Revised NCEES Licensing Exam On March 2-3, over twenty licensed Professional Engineers in software engineering gathered at the University of Texas at Arlington to attend an Item Writing Workshop sponsored by the USA-based National Council of Examiners for Engineering and Surveying (NCEES). It is believed to be largest gathering to date of US engineers licensed in the field of software engineering. (The participants included Don Bagert, FASE Professional Issues Editor.) NCEES provides engineering licensing examinations for jurisdictions throughout the USA. The purpose of the March 2-3 workshop was to write the first draft of questions to be used as part of a planned revision of the NCEES Electrical Engineering Principles and Practice of Engineering (P&P) Examination. The P&P exam is one of the last steps required for licensing as a Professional Engineer (PE) in the United States; a minimum of four years of experience under the supervision of a licensed PEs is required before taking the P&P. The examination is eight hours long, with four-hour morning (AM) and afternoon (PM) components. The planned revision of the Electrical P&P exam would revise the PM component so that it would test one of three areas, of one which is named "Computers" - intended primarily for the computer engineering community, which does not have a separate P&P exam. A portion of the Computers component under development will be on Software i.e. it will test the software engineering skills of the electrical/computer engineering practitioners who take the exam. It is for this Software section for which the workshop participants drafted potential questions. The revised Electrical P&P Exam is not expected to implemented until at least 2002. ###################################################################### By: Don Bagert (Professional Issues Editor) Countries with Subscribers to FASE There are currently there are subscribers to FASE from 58 countries and provinces on six continents, according to Internet domain codes: Argentina Australia Austria Bahrain Belgium Brazil Brunei Darussalam Bulgaria Canada Chile China Croatia Denmark Finland France Germany Hong Kong Iceland India Indonesia Ireland Israel Italy Japan Korea, South Kuwait Latvia Lithuania Madagascar Malaysia Mexico Netherlands New Zealand Norway Pakistan Poland Portugal Russian Federation Saudi Arabia Singapore Slovak Republic Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Tunisia Turkey Ukraine United Kingdom United States Uruguay Viet Nam Yugoslavia Zimbabwe [Editor's Note: Hong Kong is a province of the People's Republic of China, and the status of Taiwan is best left to the politicians. No international incidents, please!] Since the last such listing (in the March 2000 FASE), there have are now subscribers with domain codes for Croatia, Mexico, the Russian Federation, the United Arab Emirates, Viet Nam and Zimbabwe, while there are no longer subscribers with domain codes for Greece, Hungary or the Chinese province of Macau. It is possible there are subscribers from countries or provinces other than the ones shown above (for instance, if someone is using an acm.org alias as their subscription address); please contact me at Don.Bagert@ttu.edu if any such omissions have been made. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: Frank Young ITiCSE Working Group for Instructors of Capstone Courses This is from http://www.cs.ukc.ac.uk/events/iticse2001/wk.htm, which describes the Working Groups available at the 6th Annual Conference on Innovation and Technology in Computer Science Education (ITiCSE), which 25-27 June 2001 in Canterbury UK: Resources for instructors of capstone s/w development courses Tony Clear, tony.clear@aut.ac.nz Frank Young, frank.h.young@rose-hulman.edu We propose to collect and organize resources for capstone software development courses. Our goal is to provide capstone software development course instructors with a collection of web-based resources. We anticipate that the web site will allow instructors of capstone courses to learn from the experiences and errors of others. The desired result is an improvement in the quality and effectiveness of capstone courses in general. Instructors for these courses must consider many important issues. Most instructors who supervise capstone courses fail to consider every one of the important issues. It is fairly obvious that one reason for this is that the number of issues is quite large. Another reason is that instructors who are inexperienced in supervising such projects may be unaware of the importance of certain issues. What is needed is a community resource that all capstone instructors, new and experienced, are able to consult. The information placed there should enable all instructors of capstone software development courses to improve their courses. There is no desire to codify any recommended uniform standards for such courses. We seek quality through the diversity that results from informed choice. For more information about ITiCSE and this Working Group, please consult the conference web page at http://www.cs.ukc.ac.uk/events/iticse2001 ###################################################################### From: Ann Sobel Call For Papers for Advances in Software Specification and Verification minitrack Part of the Software Technology Track at the Thirty-Fifth Annual HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES on the Big Island of Hawaii January 7-10, 2002 Additional detail on the web site: http://www.hicss.hawaii.edu Modern society is increasingly dependent on large-scale software systems for reliable functioning of critical infrastructures, including defense, energy, communication, transportation, finance, and healthcare. As a result, the consequences of failures are becoming increasingly severe. The Advances in Software Specification and Verification minitrack focuses on research and applications that will drive use of rigorous specification and verification technologies, particularly for such large-scale systems. We encourage submission of papers in the following areas: * New techniques for specification and verification of software systems * Trace- and sequence-based approaches to specification * Complexity reduction methods for scaling up specification and verification techniques * Developing specifications that enable effective verification * Specifying and verifying properties including security and survivability * Specification and verification techniques for legacy and component-based systems * New model-checking-based approaches to verification * Industrial case studies in software specification and verification * Technology transfer of specification and verification techniques * Engineering practices for specification and verification * Tools for specification and verification support Minitrack Co-Chair contact information: Ann Sobel Computer Science and Systems Analysis Department 230 J Kreger Hall Miami University Oxford, OH 45056 513-529-7541 (voice) 513-529-1524 (fax) sobelae@muohio.edu Richard Linger Software Engineering Institute Carnegie Mellon University 4500 5th Avenue Pittsburgh, PA 15213 301-926-4858 (voice) 412-268-6874 (voice) 412-268-5758 (fax) rlinger@sei.cmu.edu IMPORTANT DEADLINES March 31, 2001 Abstracts submitted for guidance and indication of appropriate content. June 1, 2001 Full papers submitted to Minitrack Chairs. Contact minitrack chairs for submission instructions. August 31, 2001 Notice of accepted papers sent to Authors. October 1, 2001 Accepted manuscripts sent electronically to the publisher. Authors must be registered for the conference by this date. INSTRUCTIONS FOR PAPER SUBMISSION 1. Contact the Minitrack Chair in advance for specific submission instructions. Otherwise, submit six (6) copies of the full paper, consisting of 22-26 double- spaced pages, including diagrams, directly to the appropriate Minitrack Chair. (NOTE: The final paper will be 10 pages, double-column, single spaced.) 2. Do not submit the manuscript to more than one Minitrack Chair. Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. 3. Each paper must have a title page to include title of the paper, full name of all authors, and complete addresses including affiliation(s), telephone number(s), and e-mail address(es). 4. The first page of the manuscript should include only the title and a 300-word abstract of the paper. TRACKS AT HICSS-35 * Collaboration Systems Co-Chairs: Jay Nunamaker; Email: nunamaker@bpa.arizona.edu Robert O. Briggs; Email: bbriggs@GroupSystems.com * Complex Systems Chair: Robert Thomas; Email: rjt1@cornell.edu * Decision Tech. for Management Chair: Dan Dolk; Email: dolker@redshift.com * Digital Documents Chair: Stephen Smoliar; Email: smoliar@pal.xerox.com * Emerging Technologies Co-Chairs: Ralph H. Sprague; Email: sprague@hawaii.edu Hesham El-Rewini; Email: rewini@cs.unomaha.edu * Information Technology in Health Care Chair: William Chismar Email: chismar@dscience.cba.hawaii.edu * Internet & the Digital Economy Co-Chairs: David King; Email: dave@comshare.com Alan Dennis; Email: ardennis@indiana.edu * Organizational Systems & Tech. Chair: Hugh Watson; Email: hwatson@uga.edu * Software Technology Chair: Hesham El-Rewini; Email: rewini@cs.unomaha.edu http://cs.unomaha.edu/-rewini/SWT-CFP.html For the latest information; visit the HICSS web site at: http://www.hicss.hawaii.edu HICSS conferences are devoted to advances in the information, computer, and system sciences, and encompass developments in both theory and practice. Invited papers may be theoretical, conceptual, tutorial or descriptive in nature. Submissions undergo a peer referee process and those selected for presentation will be published in the Conference Proceedings. Submissions must not have been previously published. CONFERENCE ADMINISTRATION: Ralph Sprague, Conference Chair Email: sprague@hawaii.edu Sandra Laney, Conference Administrator Email: hicss@hawaii.edu Eileen Dennis, Track Administrator Email: eidennis@indiana.edu For the latest information; visit the HICSS web site at: http://www.hicss.hawaii.edu 2002 CONFERENCE VENUE: Hilton Waikoloa Village (on the Big Island of Hawaii) 425 Waikoloa Beach Drive Waikoloa, Hawaii 96738 Tel: 1-808-886-1234 Fax: 1-808-886-2900 http://www.hilton.com/hotels/KOAHWHH/index.html?show=all www.hiltonwaikoloavillage.com NOTE: December 1 is the deadline to guarantee hotel room reservation at conference rate. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Advance Programs ###################################################################### From: Tom Hilburn Personal Software Process(SM) and Team Software Process(SM) 2001 Summer Faculty Workshops PSP(SM) Workshop: June 13-16, 2001 TSPi Workshop: June 18-21, 2001 Marietta, Georgia Apply online at http://www.spsu.edu/oce/psptsp BACKGROUND The Software Engineering Institute (SEI) and Southern Polytechnic State University are presenting summer faculty workshops for the Personal Software Process(SM), or PSP(SM) and the Introductory Team Software Process (TSPi). These workshops will provide training for faculty who are interested in using PSP and/or TSPi in an academic computing program such as computer science, information science, software engineering, or computer engineering. Developed by Watts Humphrey at the SEI, the PSP is designed to help students and engineers organize and plan projects, track performance, manage software quality, and analyze and improve personal process. The TSPi, also developed by Humphrey and based upon the PSP, guides students through the steps of a team software project course. The pre-defined TSPi process enables students to spend less time on process definition and planning, and more time on designing a quality product. ADVANTAGES OF PSP AND TSP The PSP and Team Software Process(SM) or TSP(SM) are enjoying increasing popularity in industry. Using these technologies, software development teams have achieved: - cost and schedule results within 8% of projected plans - near zero defects in delivered products - 2x productivity increases - employee turnover rates near zero We expect these results to create an increasing demand for PSP- and TSP-trained engineers. More detailed information on the benefits of PSP and TSP is available on the SEI web site at http://www.sei.cmu.edu/tsp. WORKSHOP SCOPE AND REQUIREMENTS The PSP workshop includes instruction and discussion of PSP concepts, techniques, and process elements. PSP exercises and programming assignments are used to reinforce lecture topics. Participants must be conversant with a high-level language (preferably C, C++, Ada, Java, or Pascal) and bring a laptop system that supports software in that language. The TSPi workshop will concentrate on the planning, organization, and execution of a TSPi course. It will examine the objectives of the TSPi and then explore the TSPi process, student roles in the process, and the forms and scripts required to support the process. Group exercises will emphasize an instructor's role in guiding students through the TSPi process. An automated tool used for estimating, planning, tracking, and quality management will be made available. In addition, the workshop will address issues found in the adoption of PSP and TSPi in academic environments and offer solutions. It is assumed that faculty enrolling in the TSPi workshop are familiar with the PSP. Faculty may attend the TSPi workshop if they have previously attended a PSP workshop, taught a PSP course, have knowledge of PSP concepts and techniques, and/or are capable of writing programs using PSP Level 2 or higher. PSP workshop participants are expected to bring a laptop with a compiler or development system for the language in which they will do their PSP assignments. While the TSPi workshop will not require any code development, the TSPi support tool uses MS Excel. DATES PSP Workshop: June 13-16, 2001 TSPi Workshop: June 18-21, 2001 LOCATION Southern Polytechnic State University, Marietta, GA 30060 (Marietta is a suburb of Atlanta, 13 miles North of downtown.) SPONSORS The Software Engineering Institute Southern Polytechnic State University's Department of Computer Science and Office of Continuing Education TEXT BOOKS The following Addison-Wesley textbooks are provided to participants of the PSP Workshop: Introduction to the Personal Software Process by Watts Humphrey, ISBN: 0-201-54809-7 A Discipline for Software Engineering by Watts Humphrey, ISBN: 0-201-54610-8 The following Addison-Wesley textbook is provided to participants of the TSPi Workshop: Introduction to the Team Software Process by Watts Humphrey, ISBN: 0-201-47719-X More information on each of these titles can be found on the Addison-Wesley web site: http://www.awl.com/ INSTRUCTORS Bob Cannon is a professor of Computer Science at the University of South Carolina (USC). As a visiting scientist at the SEI, Bob has worked in technology transfer for PSP and TSP and also in PSP course development. He has taught PSP courses for the SEI, the South Carolina Research Authority, and at USC. Jorge L. Diaz-Herrera is a professor of Computer Science at Southern Polytechnic State University. Jorge spent almost five years teaching in the Master of Software Engineering (MSE) program at Carnegie Mellon and has taught several offerings of the SEI's Domain Engineering public course. He has taught TSPi in a software engineering project course at SPSU. Tom Hilburn is a professor of Computer Science at Embry-Riddle Aeronautical University. Tom has been a leader in efforts to integrate software engineering and the PSP into academic computing programs. He has used the TSPi in a software engineering project course for the past two years. WORKSHOP FEES PSP workshop $400 for faculty from U.S. schools $500 for international faculty TSPi workshop $400 for faculty from U.S. schools $500 for international faculty Both workshops $700 for faculty from U.S. schools $900 for international faculty (Fee includes a reception, breaks, and continental breakfasts; fee does not cover transportation, other meals, or lodging.) Apply online at http://www.spsu.edu/oce/psptsp Questions about workshop content may be addressed to any of the workshop instructors: Tom Hilburn at hilburn@db.erau.edu or (904) 226-6889 Bob Cannon at cannon@sc.edu or (803) 777-6853 Jorge Diaz-Herrera at jdiaz@spsu.edu or (770) 528-5558 Questions about registration or reservations may be addressed to Dawn Ramsey at dramsey@spsu.edu or (770) 528-7240. Application deadline: June 1, 2001 (SM) Personal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie Mellon University. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Contact and General Information about FASE FASE is published on the 15th of each month by the FASE staff. Send newsletter articles to one of the editors, preferably by category: Articles pertinent to academic education to Tom Hilburn ; corporate and government training to David Carter ; professional issues and all other categories to Don Bagert . If the article is for a FASE topic where there is a guest editor, the submission should instead be to that person. 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 70 characters per line (71 including the new line character). This 70-character/line format must be viewable in a text editor such as Microsoft Notepad WITHOUT using a "word wrap" facility. All characters (outside of the newline) should in the ASCII code range from 32 to 126 (i.e. "printable" in DOS text mode). _____ Subscribe/Unsubscribe Information (as of February 15, 2000) Everyone that is receiving this by email is on the FASE mailing list. If you wish to leave this list, send a message to and, in the text of your message (not the subject line), write: unsubscribe 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 For instance, if your name is Jane Smith, write: subscribe fase Jane Smith But what if you have something that you want to 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 For instance, if your name is Jane Smith, write: subscribe fase-talk Jane Smith Please try to limit FASE-TALK to discussion items related to software engineering education, training and professional issues; 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! (Subscriptions can also be maintained through the Web via http://lyris.acs.ttu.edu. From there, click on "TTU Faculty Mailing Lists", and then either "fase" or "fase-talk", depending on which list you desire.) _____ Back issues (dating from the very first issue) can be found on the web (with each Table of Contents) at in chronological order, in reverse order, or through ftp at . _____ The FASE Staff: Tom Hilburn -- Academic Editor Embry-Riddle Aeronautical University Department of Computing and Mathematics Daytona Beach FL 32114 USA Phone: 904-226-6889 Fax: 904-226-6678 Email: hilburn@db.erau.edu URL: http://faculty.erau.edu/hilburn/ David Carter -- Corporate/Government Editor 6212 Mil Mar Blvd Alexandria LA 71302 USA Phone: 318-767-2339 Email: dacarter@bayou.com Don Bagert, P.E. -- Professional Issues/Misc Editor and Web/Listmaster Department of Computer Science 8th and Boston Texas Tech University Lubbock TX 79409-3104 USA Phone: 806-742-1189 Fax: 806-742-3519 Email: Don.Bagert@ttu.edu URL: http://www.cs.ttu.edu/faculty/bagert.html 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