Published by the IEEE Computer Society
|Topically Reactive Publications|
|Topically Proactive Publications|
|Paring It Down|
|Making It Happen|
PDFs Require Adobe Acrobat
• The effect of software development practices on legal issues. For example, to what degree do developers' software engineering practices affect software product liability?
• Metaphors for software development. What are some of the metaphors other than engineering that have been suggested for software development? Does theatre or agriculture work? (For example, see "Beyond Requirements: Software Making as Art" by Rob Austin and Lee Devin in the Jan./Feb. 2003 issue of IEEE Software.)
• Email-based work environments. How can we handle and exploit environments whose communications are heavily automated?
• Resource-aware computing. How can software be written to dynamically manage and optimize resources such as power and bandwidth?
• The "-ilities." This topic seems to come up almost every year. We are all aware of software's "-ility" constraints: maintainability, reliability, and so on.
• The impact of market forces on software engineering practices. This includes access to cheaper labor.
• Better understanding of software engineering by business managers, and vice versa. How can we get managers to better understand software development? How can we get software developers to better understand management issues?
• Career management. How can software developers reinvent themselves in response to the rapid changes our field is undergoing in both its technology and its organizations? What impact has the automation of so many software development tasks had on people's careers?
• Career comparisons across cultures and continents. What does a software developer's career in various parts of the world look like?
• Pros and cons of SWEBOK. What significance will the Engineering Body of Knowledge project have on the practicing software development community? What are its ramifications?
• Characteristics of future programmers. Tomorrow's programmers will have been raised on high-speed connections and peer-to-peer resource sharing. Will they differ from today's programmers?
• Software engineering education is not training. Fundamental principles distinguish the two. What should software engineering education not teach?
• New user interfaces. How are developers meeting the need for today's software to operate with a variety of different input devices, from cell phones to full-screen Web browsers?
• The growth and integration of interoperable, heterogeneous systems. As the number of systems with which the "typical" system must interact increases, how do we keep track? Are these "systems of systems" or just "systems"?
• Design and architecture for security. How can we build security into the architecture and design of systems?
• Planning and building for evolvability. The old saying is "plan for change." What effect does evolvability have on our systems? How can our designs and architecture support evolvability?
• Commercial off-the-shelf system legacy issues. What kinds of legacy issues are COTS integrators encountering as systems age, vendors go out of business, and product support is phased out?
• Obfuscation of automation. Is automation making developers and users lose sight of what is being done with issues such as security and correctness on their behalf?
• Safe programming by nonprogrammers. Can nonprogrammers program safely? If not, can anything be done about it?
• Truisms, "urban" legends of software engineering. We've all heard them and probably used them in an example or in making a point. For example, did a jet fighter flip upside down every time it crossed the equator? Does the cost of repairing an error increase by a factor of 10 for every additional phase to which it leaks before being discovered? Does adding people to a late project just make it later? Who said these? Can they be documented? In what context was the original statement made?
• Borderless computing. It is now possible for a software system to have its database hosted in Greece, its interface and client-side processing software retrieved from a Web server in Mexico, and the server application executed on a computer in the Ukraine. What effect does geographically dispersing a software system have on development?
• Technology transfer. Every year, academics and scientists in research laboratories make dozens if not hundreds of important new discoveries (often funded by industry) about software development. At the same time, software practitioners encounter hundreds if not thousands of problems that these new discoveries could solve. How can technology transfer be facilitated? Do any particular models work?
• Software practice and legal issues
• Metaphors for software development
• How to handle and exploit electronic-based environments
• The "-ilities"
• Commercial off-the-shelf and legacy issues
• Better understanding of software engineering by business managers and vice versa
• International career comparison
• Borderless computing
• Resource-aware computing
• New user interfaces
• Software engineering education