Lawrence Bernstein

Master's Degrees in Software Engineering: An Analysis of 28 University Programs

The software engineering institute published the last reference curriculum for a masters in software engineering in 1991. In 2007, a coalition from academia, industry, and government began creating a new reference curriculum. An early step was to establish a baseline of graduate education by surveying 28 masters programs in software engineering. The survey was largely limited to US schools. Key findings showed that the universities viewed software engineering largely as a specialization of computer science, that faculty size is generally small with few dedicated professors, and that new masters programs continue to start despite the decrease in computer science majors over the past few years. We used the IEEE Computer Societys Software Engineering Body of Knowledge (SWEBOK) to structure our analysis of the 28 curricula, focusing primarily on courses and topics required or semirequired of all students. (A course is semirequired if there is at least a 50 percent chance a student must take it.) Major findings show wide variation in the depth and breadth of SWEBOK coverage in required and semirequired courses, less than 40 percent of all programs requiring an introductory course on software engineering, and many universities having required and semirequired courses that are peripheral to SWEBOK.

Assessing attitude towards, knowledge of, and ability to apply, software development process

Software development is one of the most economically critical engineering activities. It is unsettling, therefore, that regularly published analyses reveal that the percentage of projects that fail, by coming in far over budget or far past schedule, or by being cancelled with significant financial loss, is considerably greater in software development than in any other branch of engineering. The reason is that successful software development requires expertise in both state of the art (software technology) and state of the practice (software development process). It is widely recognized that failure to follow best practice, rather than technological incompetence, is the cause of most failures. It is critically important, therefore, that (i) computer science departments be able assess the quality of the software development process component of their curricula and that industry be able to assess the efficacy of SPI (software process improvement) efforts. While assessment instruments/tools exist for knowledge of software technology, none exist for attitude toward, knowledge of, or ability to use, software development process. We have developed instruments for measuring attitude and knowledge, and are working on an instrument to measure ability to use. The current version of ATSE, the instrument for measuring attitude toward software engineering, is the result of repeated administrations to both students and software development professionals, post-administration focus groups, rewrites, and statistical reliability analyses. In this paper we discuss the development of ATSE, results, both expected an unexpected, of recent administrations of ATSE to students and professionals, the various uses to which ATSE is currently being put and to which it could be put, and ATSEs continuing development and improvement.

Eliminating aversion to software process in computer science students and measuring the results

If the level of adoption of software engineering best practice is to be increased in industry, then an appreciation of its importance must be conveyed to computer science students. Accomplishment of this goal is often severely hampered by the fact that many computer science faculty view the software process as intellectually shallow and that many computer science students come to the field with an aversion to the oppressive discipline which they perceive to be required to follow it. We have devised a method of forcing students to recognize the necessity of software engineering best practice by bringing them to the realization that without it they will fail, not in their course work, but in real-world software development projects. The method has been tested twice at Stevens Institute and is about to be used at a number of other universities. Evaluation of results is being done through the use of two standard instruments, the Felder Learning Styles Inventory and the Academic Locus of Control Scale and of a novel Attitude Toward Software Engineering (ATSE) instrument designed by the authors.

The Current State of Software Engineering Masters Degree Programs

A broad coalition of professionals from academia, industry, and government, under sponsorship of the US Department of Defense, is building a new model curriculum for a Masters Degree in Software Engineering (SwE). Before beginning to create such a model, a study of 28 programs was completed to determine the current state of SwE masters-level education in the US and abroad.

Software Fault Tolerance Forestalls Crashes: To Err Is Human; To Forgive Is Fault Tolerant

Abstract Software Fault Tolerance prevents ever-present defects in the software from hanging or crashing a system. The problem of preventing latent software faults from becoming system failures is the subject of this chapter. Software architectures, design techniques, static checks, dynamic tests, special libraries, and run-time routines help software engineers create fault tolerant software. The nature of software execution is chaotic because there are few ways to find singularities, and even those are rarely practiced. This leads to complex and untrustworthy software products. The study of software fault tolerance starts with the goal of making software products available to users in the face of software errors. Availability is a mathematical concept; it is the Mean Time-To-Failure divided by the Mean Time-To-Failure plus the Mean Time-To-Repair. The idea is to make the Mean Time-To-Failure as large as possible and the Mean Time-To-Repair as small as possible. Continuing with Reliability Theory we can express the Mean Time-To-Failure as the reciprocal of the failure rate. Assuming an exponential reliability model the failure rate is the expected value of the reliability of the system. This chapter shows how these quantitative concepts can be used to make software engineering tradeoffs. First, there is a historical perspective on, and problems with, the study of software fault tolerance. Then new approaches are presented with a theme of making it possible to trade-off software execution time, complexity, staff effort, and the effectives of the staff to achieve desired system availability.

Teaching old software dogs, old tricks

Several new ideas have been presented, that set the lines for future research in the field. • There is a need of understanding better how to shape software product lines for small software companies. Research has already been performed. Hoiwever, there is not a well established understanding of the issues. More models and more experiments are required, as the ongoing effort at Fraunlaofer IESE on the KobrA methodology. • The importance of a product line approach beyond the simple reuse of software components should be more clearly stated and defined. Suitable supporting tools should be developed. • The role of government agencies and initiatives could be critical in establishing stateor country-wide framework that could support product line initiative of local companies or even product lines that span multiple local companies, as is the case for the state of Georgia. • Clear taxonomies and experimentations of economic models for product lines should be developed, to provide companies more precise figures of what they can expect from product lines and what should be their upfront investments. • Relationships between product lines, corporate environments, and other methodologies, process improvement frameworks, and tools should be clarified, to better understand when and how it is appropriate to start a product line. This is in particular important for the ISO and the CMM certifications and for exareme programming and other lightweight methodologies, given their relevance in the software industry.

Network Management Isn't Dying, It's Just Fading Away

Dear reader; thank you for your patience and support as I retire from being your Thresholds editor. I leave you with yet another controversial article; one that I trust will provoke thought and introspection. Our industry has continued be an adopter of new concepts and software technology. As our efforts focus more on embedded software solutions. I implore you not to lose sight of the innovative tradition we created. Don’t become timid in the face of the hardware design bullies. Developing trustworthy software is as much an intellectual challenge as any design activity. Godspeed.

Tools for outcomes assessment of education and training in the software development process

Workshop Summary The purpose of this workshop is to provide university faculty and software development professionals with a background on work already done in developing a tool (ATSE) for measuring students’ attitudes to software process, and to involve them in the exploration of its use and further development. The outcome of this workshop will include guidelines for application of ATSE and other instruments within academic computer science programs and in industrial SPI efforts. The workshop will also involve the participant in the evolution of the various instruments.

The System is the Solution

Today’s networks and services break down office walls. People’s offices are wherever they are, not where their desks are, and databases stretch around the world. Lawyers carry entire legal libraries into court with a four pound PC. Express delivery drivers update their database the instant a recipient signs the new keypad. There is a tremendous change in the physical structure of business, brought about by network computing and in the need for trustworthy software to operate it. Applications are neither here nor therethey are everywhere with the Internet dynamically connecting them. Computer scientists and software engineers need to embrace system engineering technology to stay current. Those who understand Software intensive Systems of Systems (SiSOS), a term coined by Barry Boehm of USC, are in great demand. Problem solvers, not coders, are needed to deal with these virtual companies. COMPUTERWORLD Forecast 2007 projects that employment candidates with application development, project management, business analysis, and security and product-line help desk skills will be the first hired with handsome salaries.