Forum for Advancing Software engineering Education (FASE) Volume 10 Number 06 (125th Issue) - June 15, 2000 939 subscribers Note: If you have problems with the format of this document, try ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Table of Contents Next Month's Topic: Relevance of Mathematics in SE Education News Items Engineering Times Viewpoint Article by an NSPE National Director ICSE 2000 Report Software Engineering Categorization Software-Engineering.org Calls for Participation Retraining Survey Advance Programs TOOLS EUROPE & TOOLS USA Contact and General Information about FASE ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: Peter B. Henderson Next Month's Topic Relevance of Mathematics in Software Engineering Education Peter B. Henderson Butler University Indianapolis, IN phenders@butler.edu As in traditional engineering disciplines, some software engineers believe mathematics(logic, discrete) and math thinking are important for the practicing software engineer. Others feel mathematics and math thinking modes of thought are less relevant for the practicing software engineer(see the recent study by Tim Lethbridge published in IEEE Computer, May 2000 or http://www.site.uottawa.ca/~tcl/edrel/). The two extremes in software engineering education are: a) Make mathematics and mathematical thinking an integral component of the curriculum from day one, and relate the mathematics to the development of high quality software. b) Minimize the exposure to mathematics and math thinking, and focus on the more practical aspects of software development. To obtain a general opinion on this issue, please send your response to the following survey question to phenders@butler.edu "Mathematic(logic, discrete math) and mathematical thinking are important in software engineering education." 1) Strongly Agree 2) Agree 3) Neutral 4) Disagree 5) Strongly Disagree If you have more to contribute, please send a short 1-3 paragraph statement outlining your opinions, thoughts, position, flames, etc. on this issue to Peter B. Henderson (phenders@butler.edu) for inclusion in the July 2000 issue of FASE. The results of the survey will also be published there. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ News Items ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) Engineering Times Viewpoint Article by an NSPE National Director The June 2000 issue of the Engineering Times (published by the USA-based National Society of Professional Engineers) ran the Viewpoint "Taking a Proactive Approach to Software Engineering" on page 5. The article is by Roger Zimmerman, a NSPE National Director from New Mexico. (However, the articles notes that " 'Viewpoint' articles...may or may not reflect official NSPE views.") Some highlights of the article: * "While software engineering has not developed out of the traditional engineering disciplines, expectations of reliability, usability, economy, and efficiency - the cornerstones of engineering applications - exist just the same." * "I believe that it is time for [Professional Engineers] to view software engineering in a new and creative way, to recognize that the licensing system needs modification to accommodate those engineers, to encourage software engineers to be licensed..." * "NSPE should actively work with NCEES to improve the examination system so that a broad base of engineering professionals can be recognized as competent." * "If NSPE is to be the professional society that represents engineers of the future, we must establish communications with the technical societies, including ACM, and convince them that the public will be better served if we can collectively develop ways to prevent those who are incompetent or unethical from calling themselves engineers." The entire article can be found online at http://www.nspe.org/etweb/16-00viewpoint.asp ###################################################################### By: Don Bagert (Professional Issues/Misc Editor) ICSE 2000 Report The 22nd International Conference on Software Engineering was held in Limerick, Ireland on June 4-11. Included for the first time was a "Software engineering Education and Training" (SEAT). This track of the program included Technical Papers, Panels, and Teaching Demos. In addition, in the "Future of Software Engineering" track, Mary Shaw of Carnegie Mellon University presented a paper entitled "Software Engineering Education: A Roadmap." Concerning professional issues, Grady Booch, Chief Technical Officer of Catapulse, USA, in his invited presentation "The Future of Software", briefly discussed the IEEE-CS/ACM Software Engineering Body of Knowledge (SWEBOK) project, stating that although SWEBOK was not perfect, it was a good start. (This is not an exact quote. Also, it should be mentioned that Booch was formerly the Chief Scientist for Rational Software Corporation Rational, which provides corporate support for the SWEBOK project.) ###################################################################### From: Mike McCracken Software Engineering Categorization 5/15/00 A categorization scheme for understanding the design of software systems Michael McCracken I have developed an informal categorization scheme to help understand the different models of computing that are used by engineers and computer scientists. The purpose of the categorization is to apply it to the education of software developers. Jackson's problem frames are a more insightful approach to this problem, but my broader scheme seems to be useful in this context. In summary, I propose that software engineering should not be categorized as a single entity and as a result be placed in some intellectual box. It should be taught in a manner that reflects the type of software systems that are being designed. A straightforward definition of software engineering is: The application of a systematic, disciplined, quantitative approach to the development, operation and maintenance of software systems within economic, social and technical constraints under conditions of uncertainty. That sure looks like an engineering type of definition, but there are several factors that at times differentiate "regular" engineering from software engineering To begin, we need to clarify the dimensional space of software engineering. I chose to create a model that differentiates things by the type of software that is being "engineered". The three categories are: * Software for machines. This category is typically the embedded or machine centric application space. This software has little to no human interaction content. Examples include, process control systems (assuming the process is self-regulating), embedded software on chips, and signal processors. In many cases this type of software is used to replace hardware with software, or to replace human physical processes with computational artifacts. * Software for humans. This category is typically the human centered types of software, such as, MS word, a web application, and a power plant control system (where it is not self-regulating). This type of software is used to replace human mental processes with automated systems, or as in most cases, to augment human mental processes. * Information processors. This category is the catch all for giant databases (such as engineering design data bases), financial applications (Schwab's on line trading system), and back room processors for business. The difference between this category and software for humans is that it primarily contains big "off-line" applications that run with minimal human interactivity. An example would be a crew scheduler for Delta Airlines. The important part of that software is the algorithms to optimize the scheduling process. If it merely required a fancy interface, Schedulers Are Us, Inc, wouldn't be in business. Obviously, the three categories are not disjoint, and some of my examples reflect that. E.G., Schwab's on-line trading system has a large information processor component as well as software for humans component. The point of the three dimensional space is to focus on the acquisition and use of knowledge for building software in the engineering and computing domains, not to belabor what category some application belongs in. Before I present some conjectures, let me outline the core knowledge elements of software engineering that will be used to clarify the conjectures. * Software Requirements - The methods, techniques, and tools to establish the understanding of the problem to be solved by a software system. * Software Design - The principles, methods, and techniques for translating the requirements of a software system into an implementable solution. * Software Construction - The implementation strategies and techniques (i.e., programming) of constructing the artifact from the design. * Software Evolution - The methods and techniques to enhance, perfect, and modify software over time. * Software Project Management - The methods and techniques to manage the complexity of developing software system, where the complexity is associated with both the process and the product. Here are the conjectures. 1. Most of engineering education, from a computing perspective, focuses on the first category (software for machines). The techniques and skills of EE's or ME's, are focused on certain elements of software engineering that support the model of building software for machines. The education process of engineers prepares them for detailed analysis of machines. They are therefore prepared to do software requirements using their analytical skills, but not from a systems perspective, as an industrial or systems engineer would observe. Similarly, the models and representations developed are easily transformed into designs and constructed artifacts (programs). Most of that world lies in the space of continuous functions (even if digitally represented). We could assume, with some course augmentation (requirements analysis and software development processes), that they would be able to practice as software engineers in the category of software for machines. 2. Designing software for humans requires a very different approach to software engineering. Though one could argue that there is a great deal of similarity between constructing software for humans and software for machines, the argument is wrong. * Given that software for machines is derived from functions, the model of programming is different than for software for humans or information processors. Simply put, software for machines is number crunching. (The point of that comment is not to denigrate software for machines, but to emphasize the difference). * The requirements and design processes are totally different between human and machine software. The issue with requirements for humans is that humans are not controllable. A whole world of techniques and methods exists for the specification and design of human software that is quite different than the analytical approaches used to specify and design software for machines. 3. The final dimension, information processors, is primarily concerned with the representation and manipulation of information in the large. * The requirements process is quite different from software for machines, and in many cases human software as well. The differences include how to determine what data/information is relevant and then how to represent the data/information. The complexity of these problems resides in access and storage. Hard problems nonetheless, but different than the previous two categories. * The design and implementation of information processors is also different. The design/implementation is concerned with efficient access of information that maintains the integrity of the information, with the additional complexity that access methods are often not pre-defined. Here are the conclusions I draw from the above discussion. 1. Software engineering (I prefer the term, Design of Software Systems) is not the same across domains. 2. To prevent my domain versus your domain discussions, I generated a broader categorization of software types that allows us to look at the education and practices of software designers as a function of software type. 3. We can use those categories to understand the knowledge and skill required to develop software in actual domains. For example, George Burdell is an electrical engineer and builds interface cards for some new protocol for cell phones. The protocol is instantiated in software. Whether it's software or hardware, George uses many of the same analytical skills learned in electrical engineering. 4. Most engineers aren't educated in systems building. I don't think Aero or ME's go design the next Boeing 7xx after they graduate (I mean engineer the airplane, not engineer some component of the airplane). Yet software engineers do that. That is why in addition to all the other stuff, they have systems (requirements and project management) courses, just like industrial and systems engineers. If we want to make the other engineers systems (in the software context) engineers, then that has to be addressed in any type of software engineering curriculum. 5. Any individual, be they faculty or practitioner, can argue with my three categories. One argument is that no system falls into any single category. The other argument is that faculty member Joe Jones does x, and it doesn't fit into any of your categories or even the merge of two or three of the categories. The debate is non- productive. The real issue is to force the understanding that different fields build software differently, have different problems, and use different techniques to solve those problems. We should focus on how to educate people appropriately for those fields. The three categories are an attempt to prevent every school from generating their view of how to build software, to capitalize on each other's strengths, and at the same time maintain some consistency across fields. 6. The continuation of item 5 is that we need to recognize that different types of software exist. With that we can worry about the skills needed to build software and the domain knowledge of the field where the software is being built. ###################################################################### Software-Engineering.org From: Nathalie Scheier THE SOFTWARE ENGINEERING COMMUNITY This announcement is meant to inform you about a new website that is going to revolutionize the online world of Software Engineering: http://www.software-engineer.org This Software Engineering Community website is dedicated to the FREE information sharing about software engineering disciplines between software engineers (i.e. industrials, faculty members and students). The website includes: + Software Engineering News + Software Engineering Articles + Software Engineering Links + A Message Board + Job offers + Software Engineering downloads The website has specially been developed so that any of its visitors can become a CONTRIBUTOR. As a contributor, you can post a link to a website containing resources about software engineering, you can also add articles, files or messages -by yourself! By actively contributing to this website, you will facilitate the information sharing between software engineers, and you will soon find the information that YOU need. The website is now available online, and already 100 software engineers worldwide have become contributors and share their expertise every day by posting links, news, articles, and messages. We encourage you to join http://www.software-engineer.org and we hope that this website will soon become a valuable resource of information about software engineering for everyone. We appreciate your contribution to the website. Cordially, Nathalie Scheier, from the Software-Engineer.Org Development Team ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Calls for Participation ###################################################################### From: TOOLS Conferences Listserv TOOLS EUROPE & TOOLS USA The program of TOOLS EUROPE 2000 -- Mont Saint-Michel, 5-8 June and the program for TOOLS USA 2000 -- Santa Barbara, 30 July - 4 August, are available online: http://www.tools-conferences.com/europe http://www.tools-conferences.com/usa Both conferences have particularly attractive programs with the most prestigious keynote and tutorial speakers in the field. Both are held in stunning places. TOOLS is the major international conference series devoted to applications of object and component technology, with a commitment to excellence renewed by more than 30 sessions in the US, Europe, Australia and Asia. TOOLS Europe will be held in France from June 5 to June 8 in one of the world's heritage masterpieces, the Mont Saint-Michel abbey off the coast of Normandy and Brittany, an easy reach from Paris. The program (see http://tools-conferences.com/europe) includes: - Top keynotes by J. Coplien, B. Meyer, W. Pree, J. Daniels, I. Graham - 18 tutorials by leading experts in Enterprise Architecture, Patterns, Components, UML, Java, Embedded Software, and more... - 4 workshops, including J. Coplien's two day "Mastery of Patterns" workshop - 7 technical sessions by selected industry and academic presenters, architecture panel etc. - An exciting social program, with a cocktail diner at the famous "La Mere Poulard" restaurant, a visit of the of Mt St Michel Abbey, and a visit and banquet in St Malo. TOOLS USA will be the most exciting ever. The conference is sponsored by Microsoft and there will be a special track about Microsoft component technologies, with Clemens Szyperski and Jim Miller (Microsoft Research) as keynote speakers. Among the other highlights: - Keynotes also include Don Box, Martin Fowler, Kent Beck, Martin Griss and Bertrand Meyer. - Panels: Component-Based Development, with Clemens Szyperski Bertrand Meyer and other panelists, led by Roger Smith of Software Development magazine; the TOOLS language panel; Project Management panel led by Bill Duncan, former Director of Standards for the Project Management Institute (PMI); Software Technology for E-commerce panel led by Dennison Bollay, a pioneer in e-commerce technology ... - Workshops: Business Modeling; Refactoring; eXtreme Programming... - Tutorials: the most impressive list ever, from eXtreme Programming to CORBA 3, Refactoring by Martin Fowler, Advanced Microsoft COM technologies, Idiomatic Java by Angelika Langer, Adding value to the Unified Process, JINI, Real-time critical systems, Mobile Agents systems, Use Case Patterns and many more (see http://tools-conferences.com/usa for more details). - over 25 technical contributions - Great social program in the gorgeous Santa Barbara area. We hope to see you at either or both conference. For any information please consult the Web pages or write to . ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Advance Programs ###################################################################### From: Heidi Ellis via Nancy Mead Retraining Survey Greetings The Working Group on Software Engineering Education and Training (facilitated by the Software Engineering Institute) is doing some research on industry/university collaboration. Specifically, we're looking at what companies do to train non-software engineers to become software engineers. We're looking specifically at taking non-software people like MEs, EEs, Accountants, etc. and retooling them to perform software engineering jobs (i.e., we are not (yet) looking at continuing education issues). Typically the target audience are either new hires or employees making a career change. The retooling could take a variety of forms including in-house training, academic programs, a combination of these, or some other model, and may range from formal to extremely informal. Right now we are trying to get a feel for how many companies and universities participate in this sort of thing and what form these efforts take. Since many of you work in software engineering industry or faculty positions we thought we'd see if any of you are willing to provide some data points for the research by filling out the short survey below. Please send responses to Heidi Ellis (heidic@rh.edu) and any additional information is always welcome. Thank you in advance! Heidi Ellis ----------------------------------------------------------- 1. Name (optional): 2. email (optional): 3. University/Company: 4. School/Unit: 5. Department: 6. What model/plan is in place to transition people from non-software backgrounds into a software engineering position? 7. How many people approximately enter the program each year? 8. What does the student get at the end (certificate, diploma, in-degree, university degree etc.)? 9. Are there future plans to support such a program? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 academic education to Tom Hilburn ; corporate and government training to David Carter ; professional issues, and all other categories to Don Bagert . If the article 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). [NEW SUBSCRIBE/UNSUBSCRIBE INFORMATION - February 15, 2000] Everyone that is receiving this 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 and then either "fase" or "fase-talk", depending on which list you desire. 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. FASE-TALK is also used by the editors for "breaking stories" i.e. news that we feel that you would want to hear about before the next issue of FASE comes out. (We do this sparingly, though.) 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 College of Technology Motorola University 1700 Golf Road 10th floor Schaumburg IL 60196 USA Phone: 847-576-4849 Fax: 847-538-3692 Email: D.Carter@motorola.com Don Bagert, P.E. -- Professional Issues/Misc Editor and Web/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: 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