Carnegie Mellon professor and alumnus James Tomayko (HS'71,'80), a founder and former director of the Master in Software Engineering (MSE) program in the School of Computer Science (SCS), died on Monday, Jan. 9, 2006, after a long illness. He was 56.

The agile software development paradigm and plan-driven approaches each have their strengths and shortcomings. The former emphasizes rapid, flexible development, while the latter emphasizes project and process infrastructure. Many practitioners, particularly of agile methods, tend-to view software architecture in light of the plan-driven side of the spectrum. They think that architecture-centric methods are too much work, equating them with high-ceremony processes emphasizing document production. But many elements make up a successful development approach, including process, product, technology, people, and tools. Software architecture is part of product quality and isn't tied to a particular process, technology, culture, or tool. This article explores the relationship and synergies between architecture-centric design and analysis methods and the extreme programming framework. We chose to focus on XP because it's one of the most mature and best-known agile practices.

Solar Sea Power is one of the unusual technologies in history, in that it did not progress in capability much since its first invention by Jacques d'Arsonval in 1881. It has been reinvented several times since then (at least 14 instances, probably more), which is not unusual by itself, as explained in the paper, however, the lack of progress in technological sophistication is unusual, unless the design is dominated by an established, older, paradigm. Some of these repeated inventions were need-based, such as Claude's, intended for French colonial Africa; few or none matched periods of increased interest in solar power. Even though individual inventors developed Solar Sea Power (SSP), governments were considered likely to advance the technology and apply it for the first 90 years or so of its existence. Recently, this task has been abandoned by deep-pocket governments and left to small, specialized companies such as Anderson's. Examples of the former are the plant design intended for a lake in northern Italy and the mega-plant with identical technology designed under the Energy Research and Development Agency (ERDA) sponsorship by TRW, a government contractor since sold to an aerospace firm. S SP plants do not produce much electricity, but since a portion of the output is used for operation, it is free to operate, and constantly renewable. It is even more reliable than wind power, in that the temperature differences in suitable water are always there, but wind, a product of many factors, is not blowing at all times.

This paper has two objectives; discussing how to teach eXtreme Programming (XP) and how to teach it remotely as a way to enlarge critically small departments. We show how to teach XP using class projects. We also discuss some of the problems brought to effective distance education by this method and their solutions. We essentially find in this case study that XP can be studied remotely and that distance education can be used to ''staff" software engineering programs

A method for teaching software maintenance at the graduate level using software artifacts is described. Objectives, the syllabus, and assignments are included in annotated form. A discussion of the actual events and lessons learned in a prototype course is presented.

Software is no longer developed and discussed only by computer science majors. Software development and engineering is a professional concentration area in architecture, engineering and construction (AEC) fields, among many others. Graduates of AEC related fields, who are motivated by problems which can be addressed better with computation or with better computation, often return to school to pursue graduate studies devoted to understanding computation of the professional problems they encounter. These students understand discipline specific issues in their fields well. However, in contrast to computer science majors, they lack techniques that can help them formulate solutions in software engineering terms. Asking such students to take classes from computer science curricula fosters interdisciplinary thinking; however, this practice fails to address the specialized computational needs of the AEC fields. An in depth understanding of how to use software development as a problem analysis approach can provide AEC students, both in the graduate and undergraduate levels, with problem classification techniques that they need. Here, we will describe our experience in introducing graduate AEC students to software requirement elicitation and development process techniques.

The software engineering course provides undergraduates with an opportunity to learn something about real-world software development. Since software engineering is far from being a mature engineering discipline, it is not possible to define a completely satisfactory syllabus. Content with a sound basis is in short supply, and the material most often taught is at high risk of becoming obsolete within a few years.Undergraduate software engineering courses are now offered in more than 100 universities. Although three textbooks dominate the market, there is not yet consensus on the scope and form of the course. The two major decisions an instructor faces are the balance between technical and management topics and the relation between the lecture and project components. We discuss these two decisions, with support from sample syllabi and survey data on course offerings in the US and Canada. We also offer some advice on the management of a project-oriented course.

This research examines the structural complexity of software and, specifically, the potential interaction of the two dominant dimensions of structural complexity, coupling and cohesion. Analysis based on an information processing view of developer cognition results in a theoretically driven model with cohesion as a moderator for a main effect of coupling on effort. An empirical test of the model was devised in a software maintenance context utilizing both procedural and object-oriented tasks, with professional software engineers as participants. The results support the model in that there was a significant interaction effect between coupling and cohesion on effort, even though there was no main effect for either coupling or cohesion. The implication of this result is that, when designing, implementing, and maintaining software to control complexity, both coupling and cohesion should be considered jointly, instead of independently. By providing guidance on structuring software for software professionals and researchers, these results enable software to continue as the solution of choice for a wider range of richer, more complex problems.

The Software Engineering Institute (SEI) at Carnegie Mellon University started its first contract with a carte blanche opportunity and generous funding to improve the state of software engineering education. Norm Gibbs, the first Director of Education at the SEI guided efforts in this area. One of his innovations, discussed here, were the “curriculum modules” encapsulating software engineering knowledge. We describe the scope and form of the curriculum modules, together with our personal experiences of developing the prototype modules. We conclude with an informal assessment of how well the original set of SEI curriculum modules match current ideas, both about software engineering education and also about the activities and practices that make up software engineering as a discipline.

Intertwining reflective and abstract modes of thinking into the education of software engineers, especially in a course that focuses on software engineering's human aspects, can increase students' awareness of the discipline's richness and complexity while enhancing their professional performance in the field. The complexity of software development environments includes the profession's cognitive and social aspects. A course designed to increase students' awareness of these complexities introduces them to reflective mental processes and to tasks that invite them to apply abstract thinking. For the past three years, we have taught a Human Aspects of Software Engineering course at both the Technion-Israel Institute of Technology and the School of Computer Science at Carnegie Mellon University. This course aims to increase software engineering students' awareness of the richness and complexity of various human aspects of software engineering and of the problems, dilemmas, question, and conflicts these professionals could encounter during the software development process.

This technical note fits the architecture-centric methods of the Carnegie Mellon  Software Engineering Institute (SEI) into the framework of Extreme Programming (XP).These methods include the Architecture Tradeoff Analysis Method  , the SEI Quality Attribute Workshop, the SEI Attribute-Driven Design method, the SEI Cost Benefit Analysis Method, and SEI Active Reviews for Intermediate Design.This report presents a summary of XP and examines the potential uses of the SEI's architecture-centric methods.CMU/SEI-2004-TN-036We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3.

We illustrate how reflection is introduced into the teaching and learning of the human aspects of software engineering. We start with explaining the rationale for a reflective mode of thinking and its fitness to the field of software engineering. Then we outline in detail the agenda of a course that deals with human aspects of software engineering. It is suggested that the intertwining of a reflective mode of thinking into the education of software engineers in general and especially into a course that focuses on human aspects of software engineering enhance students' understanding of the essence of the discipline as well as their professional performance in the field.

The Software Engineering Institute (SEI) at Carnegie Mellon University started its firstcontract with a carte blanche opportunity and generous funding to improve the state ofsoftware engineering education. Norm Gibbs, the first Director of Education at the SEIguided efforts is thus area. One of his innovations, discussed here, were the "curriculummodules" encapsulating software engineering knowledge.

The "metaphor" is the practice of agile processes most ignored by practitioners. A metaphor is meant to be agreed upon by all members of a project as a means of simply explaining the purpose of the project and thus guide the structure of the architecture, thus it is very important for communication, both among the team and with the client. Since both customers and developers alike use the metaphor to clarify the project, a good metaphor should be easily understandable to customers, yet have sufficient content that it can guide architecture development. This paper experiments with the metaphor as a communication tool.

This is an unusual book to review for Technology and Culture. Only tangentially a history of technology, it is mostly a memoir of a key participant in the narrative, Feng-hsiung Hsu. Historians of technology can find solace in the author's oft-stated theme, that it is about "'man as a performer versus man as a toolmaker'" (p. 264). Yet most of the book seems to concentrate on the clash of strong personalities.

There are several ways that the personal software process (PSP) can bolster the principles of scientific management to provide needed artifacts. PSP data can be gathered and then collated to make early time and budget estimates more accurate. Also, PSP data indicates that the oft-repeated belief that projects should spend more time on planning and design is correct. In both cases, calculating time across cyclic development is important. A century apart, two pioneers meet to improve the often-black art of management.

The Metaphor is intended to contribute to the Agile Programming value of communication. Previously, some of the author [sic] studied the Metaphor as a means of communication among team members and between them and clients. This paper examines the Metaphor's contribution to the software architecture. Both experiments seem to reveal that the Metaphor has poor effectiveness.

I enjoyed doing the work. The work was a goal in itself for me. Seymour Cray