Content area
Full text
In large software development organizations, increased complexity of products, shortened development cycles, and heightened expectations of quality have created major challenges at all the stages of the software life cycle. As this issue of the IBM Systems Journal illustrates, there are exciting improvements in the technologies of model-driven development (MDD) to meet many of these challenges. Even though the prevalent software-development practices in the industry are still immature, tools that embody MDD technologies are finally being incorporated in large-scale commercial software development. Assuming MDD pervades the industry over the next several years, there is reason to hope for significant improvements in software quality and time to value, but it is far from a foregone conclusion that MDD will succeed where previous software-engineering approaches have failed.
INTRODUCTION
Most developers operate by sitting down with their favorite text editor and typing in their program, attempting to compile it, making changes, compiling it, testing it, and so on until the program "works." Sometimes the various reasons for design decisions are captured in comments or other documents. Often, they are lost to posterity. Those rationales and design decisions are, however, critical for the success of a long-lived, ongoing, high-quality programming product. Hence, the standard laissez faire approach to programming that many practitioners learned must be replaced by a more disciplined engineering methodology.
Various software-engineering methodologies1-5 describe processes whereby requirements, architecture, design, implementation, and testing information-along with their interrelationshipscan be captured. Why is this information preserved at all? Maintaining this captured data may be a requirement of a customer or mandated for software quality certification. In addition, it may be essential to the development organization, when the development of software extends beyond a single individual developer or development team. It can also be useful or required when teams are distributed geographically (i.e., when requirements are gathered in one city, but code is developed in another). Then this captured data becomes a vital communication link between the teams for many purposes, even as a contract between them. When a software product takes a long time to develop or has multiple versions over time, then this captured data becomes essential to support the institutional memory as team members leave the project or are required to revisit parts of the software...