|
Technically-Oriented Commentary
The Industry commentary presented within this section of the SEPA, 5/e Web site presents selected articles reprinted (with permission) from The Cutter IT E-Mail Advisor, one of the weekly e-mail bulletins from Cutter Consortium. Each of Cutter's E-Mail Advisors provides data, analysis, and advice from industry experts. Research Briefs and the Cutter Edge are free services, available to all qualified IT and business professionals. To register for any of Cutter's E-Mail Advisors, visit http://www.cutter.com/consortium/index_e-mail.html It should be noted that many of these papers are opinion pieces, and I (RSP) don’t necessarily agree with every opinion presented. However, each paper presents useful commentary that may encourage you to research a topic more fully. The following commentary is presented for your interest and enjoyment: Requirements Issues
Components and Reuse
Technology Issues
<><><><><><><><><><><><><><><><><><><><><><><><><><><> <><><><><><><><><><><><><><><><><><><><><><><><><><><> This month's issue of the *Communications of the ACM* (Vol. 41, No. 12, December 1998) focuses on the topic of requirements traceability, which is defined as "the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through the whole system's life cycle." The potential benefits of requirements traceability have created a new market of tools and spurred new thinking about software development processes. Although this all sounds quite powerful, I keep thinking that something critical will be missing at companies that rely too heavily on requirements management. That "something" is the domain knowledge the engineers building the system need to ensure success. My experience has shown that domain knowledge (knowledge of the rules, procedures, nomenclature, etc.) is more important than technical skills in successful software projects. Without it, how can we be certain the correct problem is being solved? How can we be certain the solution can withstand the forces of change that exist in every domain? Software developers are responsible for making many decisions regarding the implementation of the system. Quite often, there is no choice but to rely on their knowledge to make the right decision. Requirements experts will challenge me on these assertions. They claim that clearly documented -- and, of course, traceable -- requirements address the problem of building the "right" system more effectively than relying on developer knowledge. Moreover, well-documented requirements identify the forces of change so that developers can be certain they are appropriately addressed. This is an almost impossible point to argue: certainly, well-documented (and therefore traceable) requirements contribute enormously to the success of a software project. The more the better. But if you're like me, you're ready to discount that argument as too simplistic to be of value. I challenge anyone to name a project in which they documented its requirements to such a degree that developers weren't making important decisions using their domain knowledge. (If this were the case, why not just use automatic programming and generate the system from the perfectly defined requirements -- no developers needed? Oh yeah -- it's because we know that automatic programming has failed, too, due to the difficulty in specifying the system....) What is a manager to do? I call my approach to this problem "experiential requirements," a technique that blends domain knowledge with clearly written requirements. In this approach, developers are asked to perform the work processes of the system they are building. If they are asked to build a new data entry system, they must first do the work of the current data entry operators. This gives them immediate experience in the problem domain they are asked to solve -- experiential requirements. These developers then work with the owners of the requirements document (such as the marketing department or the project manager), codifying and documenting those requirements that are collectively deemed most important. This approach isn't needed for every release and is less useful when developers really are domain experts. Generally, however, the benefits to this approach are substantial. Developers gain an appreciation of the business problem they have been asked to solve from the perspective of the user. This allows them to suggest implementation mechanisms that customers may not have considered. More important, it builds a critical empathy between the developers and the users. The owners of the requirements document also benefit. Instead of worrying about communicating every detail of the system or problem domain, they can instead focus on those requirements that really are critical for business success. Although both sides benefit from increased clarity in communication, the ultimate beneficiary is the user, who is more likely to get a system that meets their requirements. Luke Hohmann Luke Hohmann is Vice President of Engineering at Aurigin Systems, Inc., the world's leading provider of enterprise software systems that enable companies to maximize the value of their intellectual property assets (http://www.aurigin.com). He can be reached at lhohmann@aurigin.com or through his Web site at http://members.aol.com/lhohmann <><><><><><><><><><><><><><><><><><><><><><><><><><><> <><><><><><><><><><><><><><><><><><><><><><><><><><><> I have been working with a large group of traditional software developers, introducing them to the use case technique for documenting system requirements. I have encountered some very strong and unexpected resistance to the use case approach from these developers, as represented by the following comments: 1. "Our users don't know what they want, so our users cannot develop use cases." Unfortunately, many experienced developers have encountered information system users who do not seem to know what they want from an information system. These traditional developers still believe that it is their job to try to understand the users' business and then write the use cases for the users. I believe what is really happening here is that the traditional developers and their clients don't really understand a user-centered approach to documentation. The use case describes the externally visible behaviors (e.g., screens and reports) of the interaction the user can have with a system. If the users truly have no concept of what they want out of a system, it is unlikely the successful implementation of any system is possible, regardless of what techniques or technology are used. I have found it effective to introduce the use case technique to the users by showing them generic use cases for common business processes, showing them use cases from similar systems or even from competitors' systems, starting the use case development process by mocking-up screens and reports before trying to develop the use cases, and using existing training manuals to create use cases of the users' existing systems. If, after exhausting all of these approaches to introduce the users to the use case technique, the users still say they don't know what they want from their new systems, I recommend that the project be cancelled. 2. "We need more details." Traditional developers become distressed when they read user-centered documentation. They only see externally visible behavior and are upset that they do not have any information on the processes and algorithms necessary to code the system. This is another common misunderstanding about the use case technique. Use cases will never be sufficient documentation from which to begin coding. After the use cases are written, there has to be a collection of the nonfunctional requirements of the system. These nonfunctional requirements include features like response time, availability, transaction volumes, integration with legacy systems, security, persistence strategies, etc. These nonfunctional requirements are the basis for establishing the system's architecture. After the architecture has been established, the process of identifying and designing the components of the system begins. The components of the system will contain the processes and algorithms of the system necessary to provide the functional and nonfunctional requirements of the system. The analysis and design of these components is done using a systems development methodology. The use case approach is not a complete development methodology; it is just a technique to document the externally visible behavior of the system. 3. "We want to be end-to-end developers, not specialists." Many traditional developers expect they will be fully involved in all phases of a new system's development. They will gather the requirements, plan the architecture, design the new system, do the coding, conduct the testing, train the users, and write the documentation. The full benefits of the use case technique, however, come from the specialization of duties. One team of expert-user interface designers should be working with the users to develop the "look and feel" of the system's screens and reports. Another team of business systems analysts will be working with the users to develop the sequences of behavior of the new system. A third team, consisting of systems development specialists, will be involved in the design and implementation of the components necessary to provide the functional and nonfunctional requirements of the system. It is only this third team that may be involved in writing code. We hope this third team will be using CASE tools to generate the code, will be reusing existing code and design patterns, or will even be using software component factories to implement the required system. The expectation of end-to-end development may be leading to the developers' rush to details. The sooner they collect the algorithms, the sooner they can start to code. In the three-team approach there is no inappropriate rush to code. The specification of algorithms is deliberately postponed until after the user interfaces have been designed and approved, after the use cases have been written and accepted, and after the system architecture has been created. 4. "Iterative development will result in the project's scope and budget going out of control." Traditional developers are afraid that the interactive specification of requirements by users will result in the uncontrolled increase scope of the system. The use cases are revisited at least four times over the course of the systems development life cycle. For example, the Rational Unified Process specifies that during the inception phase, use cases are employed to set the scope of the project and assist in the development of the business reasons for the development of the new system. During the elaboration phase, more detailed use cases are created to help with the setting of the system architecture and to help develop the plans for constructing the system. During the construction phase, use cases become the starting point for design and the development of testing plans. Finally, during the transition phase, use cases are used as the basis for the development of user manuals and user training. One of the most difficult lessons for traditional developers to accept is that the iterative process often actually decreases the number of components in the system. More use cases do not mean more code. Common behaviors may be abstracted from multiple components and refactored into a single component. Additional use cases may be just new sequences of services from the existing components. Major Lesson Learned After recognizing and trying to deal with these traditional developers' resistances to the use case approach, it occurred to me that what was really necessary was that the users of a system should begin all systems development and enhancement projects by creating use cases themselves. Instead of the traditional system features wish list found in most of today's requests for proposals, user- centered RFPs should consist of use cases. A user-centered RFP would specify the externally visible behaviors of the required system. The job of the developers would become proposing the design and implementation of the system that performs according to these user-developed use cases. Richard Due' Senior Consultant, Cutter Consortium's Distributed <><><><><><><><><><><><><><><><><><><><><><><><><><><> SOME THOUGHTS ON REQUIREMENTS MANAGEMENT <><><><><><><><><><><><><><><><><><><><><><><><><><><> Requirements management (RM) is simple in principle but difficult in practice. The Software Engineering Institute's (SEI) Capability Maturity Model (CMM) spells out RM in basic terms. RM means to: 1. Establish a common understanding of the requirements with the customer 2. Document that understanding 3. Make changes in an organized manner How could anything be simpler? As usual, the problems with RM come with people. Software projects are run by technical people. Technical people like to work on technical problems; we avoid or botch other problems. Requirements analysis is a technical problem. Technical people gather information, draw diagrams (use-case, data-flow, etc.), and analyze them to prepare for design. Requirements analysts use all their technical skills and apply themselves whole-heartedly. In contrast, RM is a management problem. It involves having meetings, reaching agreements face-to-face, and keeping detailed records. Technical people see RM as a clerical job and hate it. (They don't say they hate it, but they do.) Regardless of how distasteful RM might be, it must be done. So, what can a manager do to ensure that project managers do RM? The answer is, once again, simple in principle but difficult to do. The answer is one word -- help. Upper management must provide real help to project managers in the RM area. Real help is not threats to "do it right or else." Real help is realizing that RM probably won't be done well and providing the project manager with resources and direction. Real help can take several forms. The simplest help is to appoint a full-time requirements manager. This is a person who understands technical issues but likes and is good at managing things. The requirements manager performs all the face-to-face and detailed record-keeping tasks. This person has the personality and temperament to keep the customer happy and the technical people out of trouble. Another form of real help is to define clear responsibilities. There should be a poster in the project area that states precisely who is responsible for what on the project. This includes who represents the customer (if it is a large project, it could state who represents the customer's user interface issues, who represents the database issues, etc.). This reduces the amount of changing directions to try to satisfy everyone you bump into in the hall. A third way to help in RM is in the area of review boards. Any proposed change to a set of requirements should be reviewed by a group of "outsiders." These outsiders, a review board, provide a needed perspective on changes. It is unfortunate that most review boards are too slow, don't understand the project well enough, and generally become such a hindrance to the project that the project manager tells little white lies to avoid the review board. The review board is necessary and must operate in a way that does not hinder the project. The review board members must be familiar with the project, be available now, and go out of their way to help the project. RM is necessary and difficult. Project managers usually disdain it as clerical work. Upper managers must acknowledge the necessity of RM and provide real help to people so that it is performed as needed. Dwayne Phillips Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He recently wrote The Software Project Manager's Handbook, Principles that Work (http://www.cutter.com/consortium/index_books.html ), published by the IEEE Computer Society. He can be reached at d.phillips@computer.org. <><><><><><><><><><><><><><><><><><><><><><><><><><><> <><><><><><><><><><><><><><><><><><><><><><><><><><><> The Internet changes everything. Okay, now that we're through the obligatory opening for every article these days, let's focus on the key issue for business-IT alignment -- change is changing. We can no longer think of change in the traditional vein of stuff-happens- and-today-it-happens-faster. In our Internet era, there are at least two other specific types of change: disruptive change and punctuated equilibrium. Furthermore, each type of change requires a completely different strategy for both business and IT. Clayton Christensen's recent best-seller, The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail (Harvard Business School Press, 1997), describes what happens to firms caught in disruptive technological change. When a new technology undermines a particular market, such as when personal computers disrupted the mini-computer market, established firms whose managers are successful by every traditional measure often fail. Christensen's studies of the 20-year history of the disk drive market between 1976 and 1996 show that in a disrupted market, speed-to-market becomes absolutely critical. When traditional "stuff happens" change occurs, efficient change management (for example, configuration control in software) is a reasonable strategy. As Christensen shows, when faced with disruptive change, speed becomes the preferred strategy. Not an easy transition for many companies, as the demise of most mini-computer companies indicates. However, there is another type of change. While disruptive technologies might impact an industry, or a couple of industries, there are even more catastrophic changes that impact entire economies. Punctuated equilibrium is an evolutionary biology term that has crept into the business vernacular. For many years, evolutionarybiologists' sole theory was that of continual, gradual change driven by mutation and selection. However, in the early 1970s, paleontologist Stephan Jay Gould (and others) began finding fossil evidence that periods of gradual change were interrupted by short, but prolific bursts of new species creation, preceded by a time of rapid extinction. The name given to this new theory was punctuated equilibrium, or "punk-ekk." Gould's conclusion is startling -- survival had nothing to do with fitness, it was completely random and accidental. The dinosaurs were around for 130 million years and died out in some 10,000 years. Given that some semblance of corporate structure has been around for 500 years, the equivalent time we have to adapt is 1.4 days. Granted, the connections between dinosaurs and a modern corporation (or market) may be a stretch, but pundits are billing the transitionto an Internet, e-business economy as being such a defining historical transformation. "The rise and global spread of the Internet and the World Wide Web, beginning in 1994, launched the third wave of the information technology revolution ... and have resulted in a quantum leap in the evolutionary pace of organizational change," writes Jeff Papows, former president and CEO of Lotus. In punctuated equilibrium situations, which characterize many, many markets today, the ability to "adapt" becomes more critical than speed. With so many companies frantically searching for the right combination of strategy and capabilities that will lead to success, there will be more time. Amazon.com may have been the first online bookstore, but it maintains its lead because of its ability to adapt again and again and again. I recently talked to a company's e-commerce VP who indicated they have had nine major site renovations, with accompanying business operations changes, in tw years. A great example of the primacy of adaptability over speed is illustrated by Lloyd Darlington of the Bank of Montreal in "Banking without Boundaries," a chapter in Blueprint to the Digital Economy (McGraw-Hill, 1998). While Darlington offers the view that the new information economy defines the most pervasive change in banking in 300 years, he also offers keen insights into the strengths and weaknesses of traditional banks versus bank.com companies. "In the long run," writes Darlington, "we figure that while some people might be happy to accept a cheap loan from an unfamiliar provider on a Web site, few would be willing to hand over their life savings to such a provider." His message is clear: banks must adapt, but they don't have to remake their entire structure overnight. Evan Schwartz makes a similar point in Digital Darwinism (Broadway Books, 1999). "The Web may be a universe of digital information in which companies can change their appearance and switch their survival plans in a matter of weeks.... But evolution writ large still requires a more significant time frame to produce outcomes." If the above is correct, then for many companies wondering how to respond to the opportunities and threats of an e-business economy; agility, innovation, and adaptability are ultimately more important than speed. To survive punk-ekk turbulence, adaptability skills must run throughout the organization, from strategies to tactics to day-to-day operations. To thrive, organizations must be attuned to types of change -- traditional, disruptive, and punk-ekk -- and to the strategy implications of each -- efficiency, speed, adaptability. Jim Highsmith Senior Consultant, Business-IT Strategies Advisory Service <><><><><><><><><><><><><><><><><><><><><><><><><><><> <><><><><><><><><><><><><><><><><><><><><><><><><><><> Truth, like beauty, is in the eye of the beholder. As we start to assemble systems that will be used by different organizations across a supply chain, by virtual organizations, or directly by our customers, the need to define the "truth" of the information being exchanged is increasing in importance. Unfortunately, none of today's object-oriented systems development methods recognizes the significance of the viewpoints of the different observers of truth and beauty in our systems. Traditional software engineering excluded the study of the different users of a system as "out-of-scope" entities. The currently popular use case requirements technique specifically excludes the analysis of the actors or the users of a system. Most of today's object-oriented methods suffer from the carry-over of the data-centric modeling, which captured the semantics of a domain in a static representation of entities and relationships devoid of the perspective of the observers. These static models assume that there is a single, "correct" definition of data that everyone who uses the data can subscribe to and understand. For example, the class diagram found in many object-oriented methodologies displays the static relationships among classes in detailed (and sometimes arcane) notation. These static relationships equate to many of the invariants or business rules of the domain (e.g., one customer can have many orders, but one order can only have one customer). However, there is no indication in these diagrams of who establishes, owns, validates, or maintains these relationships. Neither is there any indication of the epoch (period of time) for which these relationships hold true. None of this mattered much during the past 30 years of independent, green fields custom application development. The invariants and epochs of these systems were typically small enough in scope to be assumed as common knowledge. However, as large-scale, enterprise- wide data modeling projects became the norm, many projects were delayed by weeks and even months in furious debates over the semantics and business rules of what constituted a customer, an employee, or a sale. Instead of recognizing alternative viewpoints, data modelers attempted to resolve multiple viewpoints into a single version of the truth. We may have now reached the point where the creation, maintenance, and enhancement of the single-view-of-the-truth model is economically and perhaps technically impossible to achieve. Richard T. Due' Senior Consultant, Cutter Consortium Distributed <><><><><><><><><><><><><><><><><><><><><><><><><><><> <><><><><><><><><><><><><><><><><><><><><><><><><><><> Since 1987, an increasing number of object technology system engineers have started to investigate, develop, and apply design patterns. These developers were influenced by the work of an architect, Christopher Alexander, who proposed 253 basic patterns or design guidelines that, when followed, would lead to the construction of buildings that best meet the needs of the people who would occupy these buildings. Object-oriented systems developers began to wonder if they could use a similar pattern approach to developing systems that best meet the needs of the people that would be using their systems. They wanted to know if the application of these patterns could naturally allow the reuse of proven system development solutions, enforce the principles of software engineering, and result in reusable, flexible, modular, decoupled components. Two groups of pattern enthusiasts, humorously referred to as the Gang of Four (Gamma, Helm, Johnson, and Vlissides) and the Gang of Five (Buschmann, Meunier, Rohnert, Sommerlad, and Stal), each have published collections of their patterns. The Gang of Four groups its patterns into three different categories: creational, structural, and behavioral. Creational patterns can be used to configure a system at runtime. This results in systems that are independent of how their classes and objects are created, composed, and represented. Structural patterns can be used to compose existing interfaces, classes, and objects into new objects with increased functionality. Behavioral patterns describe patterns of communication between classes and objects. The Gang of Five also groups its patterns into three categories; architectural patterns, design patterns, and idioms. Architectural patterns describe the fundamental organization of systems and subsystems. Design patterns describe how to decouple and simplify the structure and communication relationships among the subsystems and components of a system. Idioms describe how to implement particular design issues in ways specific to different programming languages. The essential features of the pattern-based approach include: Programming to Interfaces, Not Implementations -- Instead of developing rigid systems whose structure and communication pathways are set at design-time, programming to an interface means that classes and objects will be independent of the other classes and objects they must communicate with to carry out their responsibilities. This means that classes will be able to dynamically communicate with classes written in other languages and with classes that exist on other servers, and will be able to transparently accommodate the introduction of new versions of classes into the system. The existing classes only know about an interface, they have no need to understand how that interface will be implemented. Delegation vs. Inheritance -- Instead of using inheritance to add new features to existing classes and objects, new features are delegated to new classes. This preserves the encapsulation and information-hiding of the existing classes and promotes the development and reuse of small, cohesive components. Higher Levels of Abstraction -- Just as in the past we moved from programming in machine code, assembler, or third-generation language like COBOL, the patterns approach promotes programming or assembling systems at a new, higher level of abstraction. Instead of thinking in terms of code, pattern-based developers think in terms of basic information processing patterns. Reuse -- Pattern-based developers are now seeing the need to develop and apply systems development methodologies that promote the identification and reuse of patterns and components to assemble, rather than to program new systems. A powerful, but unexpected, result of the patterns-based approach has been the discovery that the documentation and use of patterns can be a powerful communication tool. We are now seeing development teams describe the systems they are working on in terms of what patterns are being used. We are seeing the different responsibilities of the individual components of these systems being described by the names of patterns. The use of these "shorthand" descriptions means that developers who are new to the project, or who are participating in a structured walk-through of the project, can immediately understand the form and the content of the component or the entire system that is being developed. Project managers, quality assurance personnel, EDP auditors, consultants, and mentors who are familiar with design patterns can almost immediately understand the intent of system, evaluate it, and offer informed suggestions for its improvement. What's next? I believe the patterns movement has the potential to revolutionize the way we design, document, test, verify, and manage the development of systems. Other groups of pattern enthusiasts are already documenting patterns for analysis, real-time systems design, and the construction of user interfaces. I also believe the patterns approach has the potential to revolutionize the way we train and educate systems. Instead of designing systems from first principles, developers will apply proven patterns to common information processing tasks. These systems will be documented with the reusable descriptions of these patterns. The understanding and application of patterns will be vital to the widespread use of language-independent components to assemble new systems. An order of magnitude increase in productivity is certainly possible, but the resistance to change from today's code-based developers and "green field" development methodologies will be a major obstacle to overcome. Richard T. Due' Richard T. Due is the President of Thomsen Due and Associates Limited, an IT training and consulting firm that specializes in object technology. He can be reached at 70544.3665@Compuserve.com or at http://ourworld.compuserve.com:80/homepages/rtdue.
<><><><><><><><><><><><><><><><><><><><><><><><><><><> DESIGN PATTERNS VERSUS METHODOLOGIES <><><><><><><><><><><><><><><><><><><><><><><><><><><> The first decade of the new century will see a shift to the development and use of component-based, Internet-enabled systems. Currently, there are two very different approaches to the development of object-oriented systems: object-oriented development methodologies and object-oriented design patterns. Object-oriented development methodologies are formal specifications of work products, development processes, techniques, and notations that are used to develop and document systems. Design patterns are informal, "grass roots" collections of designs and code that have been proven effective in the documentation and development of actual systems. One essential (and often overlooked) aspect of object-oriented design patterns is that there is an underlying theory for each design pattern, although the theory does not have to be revealed to every user of the pattern. One of the advantages of using design patterns is that the user does not have to be educated and trained in software engineering or in development methodologies, for example, to be able to produce engineered systems. Managers, users, auditors, and experienced IT personnel can all understand and reasonably discuss the criteria and trade-offs involved in using a particular pattern without having to be aware of the underlying theory of each pattern. The design pattern movement received its inspiration from an architect, Christopher Alexander, who described 253 patterns for the design of "successful" buildings. One of Christopher Alexander's architectural patterns, for example, specifies that rooms should have natural light sources on at least two walls. The owner of the house, the architect, the carpenter, the real estate agent, even the mortgage lender can all understand and verify the use of this pattern. Either there are windows on two of the walls of the room or there are not. None of the users of the pattern have to be made aware of the underlying theory as to why natural light from two directions is desirable. Alexander's theory behind the pattern is that human beings, when engaging in conversation, rely heavily on facial expressions to indicate if each person is successfully communicating with the other. In a room with only one source of light, these facial expressions are difficult to make out. Light from two sides brings out the dimensionality of the listener's face making it easier for the speaker to see and to interpret the listener's facial expressions. Supposedly, this improved communication results in improved understanding and harmony among the people in the room, which makes it a better place to live. The building is "successful" because the people living in it are happier and more productive. While we could question Alexander's proposition in this case, the facts remain that the pattern appears to work in the real world, and that no user of the pattern had to agree with, or even be aware of, Alexander's theory to successfully benefit from the pattern. Recently, I have been considering some of the underlying theory of design patterns in order to match these theories with the prevalent object-oriented analysis and design methodologies. Design patterns seem to be based on the software engineering principles of high cohesion and loose coupling of components and the reuse of proven components and designs. Object-oriented design patterns stress using delegation in preference to inheritance to develop highly cohesive components, working at higher levels of abstraction than an individual application to foster reuse of components and designs, and the use of mediators or broker components and designing to interfaces rather than designing specific components to promote the loose coupling of components. Surprisingly, the prevalent object-oriented analysis and design methodologies seem to prescribe exactly the opposite goals. For example, a key work-product in nearly every object-oriented methodology is the class diagram or object model. This diagram shows the classes in the system, their names, their attributes, and their operations, together with the relationships and communication paths among these classes, the cardinality of these relationships, and some of the business rules associated with inheritance among these classes. Inheritance is always shown in preference to delegation in the class diagram (the "Is - A" relationship). The class diagram is almost always drawn to depict classes that are found in a particular application or domain instead of classes at a higher level of abstraction. Mediators or brokers are never shown; instead, the diagram shows the direct communication paths and relationships among the classes. The cardinality (1-to-1, 1-to-many, many-to-many relationship) shown in the diagram often refers only to one application or one set of assumptions about the system. Finally, the class diagram shows the implementation of the system in terms of objects instead of interfaces. Other work- products like the object interaction diagram, which portrays the interrelationships of classes within a particular use case or scenario, or the class responsibility collaborator card technique, are similarly concerned with depicting direct communication paths among the classes in a specific application. Design patterns seem to have two major advantages over current object-oriented analysis and design methodologies. First, patternsare more easily understood and used by a more diversely experienced group of users, managers, and IT developers. Second, the use of patterns can automatically result in systems that are "successful" (robust, reusable, and understood by everyone involved in their development and operation). On the other hand, design patterns have not yet been organized into a development process that is coupled with an effective project management methodology. Because of their application-orientation, the currently popular object-oriented analysis and design methodologies cannot be used to develop successful component-based systems. However, the use of design patterns as a basis of assembling successful component-based systems will have to await the development of a formal, pattern-based development process. Richard T. Due' Richard T. Due is the President of Thomsen Due and Associates Limited, an IT training and consulting firm that specializes in object technology. He can be reached at 70544.3665@compuserve.com or at http://ourworld.compuserve.com:80/homepages/rtdue <><><><><><><><><><><><><><><><><><><><><><><><><><><> MAKING A COMMITMENT TO COMPONENT REUSE <><><><><><><><><><><><><><><><><><><><><><><><><><><> Most companies find that a serious commitment to component reuse requires a new organizational structure. One group of developers is organized into a component development group whose mandate is to create and maintain the components the company is going to rely on in the years ahead. This group invests in a repository in which to store components and develops procedures that guarantee that company components are owned and maintained in a systematic way. Most of the components developed in the course of the pilot projects must be reworked and generalized to serve a broader audience. Testing and documentation procedures must be put in place to ensure that components will be easy to evaluate and will be trustworthy, and outside components will probably be acquired to provide a greater breadth of support. Organizations that decide to move beyond developing and maintaining individual components must develop collections of components that provide the functions needed by larger classes of applications. These sets of components are, in effect, application templates, and are often referred to as component frameworks. Some organizations divide the component development and maintenance group into subgroups, each charged with developing and maintaining a specific domain framework. If a company had six major business processes, for example, it might decide to create six component groups, each charged with maintaining a framework for a single business process. At the same time that the new component development and maintenance group is being established, the remaining developers are organized into application development groups and charged with reusing components when they develop new applications. New procedures must be developed for these groups to ensure that they have the incentive to reuse components and that they are supported when they do so. Efficient channels of communication between the two types of groups must also be established. Paul Harmon Senior Consultant, Cutter Consortium Distributed
<><><><><><><><><><><><><><><><><><><><><><><><><><><> ARCHITECTURAL CARE AND FEEDING <><><><><><><><><><><><><><><><><><><><><><><><><><><> An application architecture is more like a carefully designed garden than a series of city streets. Unless you tend to its care and feeding, it will soon become unruly, overgrown with the wasteful vestiges of dead code. Ignore it long enough and you'll find that your only recourse is to engage in massive -- and very costly -- changes to correct the neglect. Successful software architectures not only describe the fundamental structural characteristics of a software system, they also adapt with relative ease to the stresses put on them by changing requirements and multiple releases. Want to add a new feature? No problem -- as long as the feature is reasonably within the design constraints and goals of the original architecture. Well-defined interfaces between subsystems contribute to parallelism among development teams. Effective subsystem design also isolates external dependencies, allowing developers to make needed changes to a given subsystem without unduly impacting other aspects of the application. Finally, bug counts for successful architectures stabilize over time, and generally remain under control for many releases. Creating such an architecture does not simply "happen." Successful architectures are thoughtfully planned and prudently implemented through a variety of well-known principles, including low coupling, high cohesion, and information hiding. That said, even the most elegant architecture will ultimately fail unless you take specific steps to maintain it. I find the following dimensions helpful when considering changes that are designed to address or prevent current or potential problems in the architecture: Technological Currency. Every complex application interacts with a wide variety of fundamental technologies. Staying current with advances in these technologies as your product evolves ensures that you won't have to engage in expensive redesign efforts. Technological advances are often the key to providing additional benefits to your users. The result? A double-win. (It doesn't hurt your marketing department either, as the phrase "new and improved" will actually mean something.) Addressing Technological Compromises. Developers are constantly struggling to release the system on time while creating appropriate long-term solutions. Successful software teams know when and how to compromise to hit the ship date. Unfortunately, "compromise" usually means "hack." The problem with such hacks is not found in the current release (which needed them to ship) but in subsequent releases, when the "compromise" makes itself known, often exacting a heavy toll to fix it. Successful architectural management means identifying such hacks and evaluating their potential damage. If the potential for damage is great enough, you must take out your pruning shears. Addressing Known Bugs. Every complex application ships with one or more bugs. Think of them as pestiferous weeds. Leaving them in your garden, especially when they are big enough to be seen, can cause an unnecessary toll on the sensibilities of your development staff. Give them some time to fix the bugs that they know about, and you'll end up with happier developers -- and a more stable architecture. License Compliance. Complex applications license critical components from a variety of vendors. In general, as described above, as they upgrade their technology, you'll respond in kind to keep pace. Of course, sometimes you may not need their new technology and are better off directing your development efforts elsewhere. But watch out: Wait too long and you risk falling out of compliance with your component vendors. Remember to review each upgrade from your component vendors. Know when you must upgrade your architecture to maintain compliance. This list is just a starting point, and I invite you to add your own categories for architectural care and feeding. Finally, be careful not to confuse radical changes in feature sets that require similarly radical changes in architectural design with the kinds of changes described above. Scaling an online application designed for 100 users to one designed for 10,000 users is not the kind of architectural change I'm talking about. Such a change would likely require a fundamental new architecture. Luke Hohmann Luke Hohmann is Vice President of Engineering at Aurigin Systems, Inc., the leading provider of intellectual asset management solutions that help companies improve business decisionmaking and institutionalize best practices for extracting full value from their intangible assets (http://www.aurigin.com). He can be reached at lhohmann@aurigin.com or through his Web site at http://members.aol.com/lhohmann <><><><><><><><><><><><><><><><><><><><><><><><><><><> THE IMPORTANCE OF SOFTWARE TESTING <><><><><><><><><><><><><><><><><><><><><><><><><><><> Software robustness is a problem that everybody cares about but few people address in their products. The average project has several weeks devoted to testing, mostly in the weeks before deployment. Of course, most software ends up behind schedule and over budget, and testing is the first thing to get reduced or cut. Thus, much commercial software gets only a couple of days of testing before it is shipped. In the high-pressure world of the Internet, this model seems reasonable, as everyone rushes to get their products to market faster than their competitors. Since the next version will be released in just a couple of months, it makes sense to let the bugs pile up after release and fix them all for the next version, right? Of course, there are a lot of problems with this model. If you let your software ship with significant bugs that affect the experience of many users, you will quickly whittle away at the quality associated with your company's brand. People will always remember you for the low quality of your first release. Another reason why this model doesn't make sense is that as the software development cycle goes on, the cost of finding and fixing a single bug in software grows enormously. If a problem is caught in the requirements phase, it costs about $139 to fix. By the time coding begins, the cost rises to nearly $1,000 per bug. If the bug is not caught until after the project is completed, the costs rise significantly. For example, many companies have testing teams whose job it is to bang on a product extensively after the coding phase is complete. For these people to find bugs, and for those bugs to then be fixed, the average cost is over $7,000 per bug. If bugs are not caught and fixed until the software is deployed, the cost rises to over $14,000 per bug -- more than 100 times more money per bug than if a bug is caught in the initial phase of development. Clearly, software doesn't have to be 100% bug free. In fact, one of the hardest problems with testing is to know when to stop. If your company puts a team of testers on a project, and they spend four weeks on the finished product, they may find a lot of bugs the first week, some the second week, few the third week, and none the fourth week. But just because they found no bugs in the fourth week doesn't mean there are none. There is no practical way to prove that any piece of real world software is devoid of bugs, even a well-tested piece of software. In addition, functionality for expert users of software often doesn't get tested as well as the basic functionality, because testers are rarely expert users. No one wants to get a reputation for software that is not robust in the eyes of their expert users, because expert users have an impact on the usage habits of novice users. If these users get upset, your entire user base could slowly migrate to another product, even if you tested it fairly thoroughly! Testing is generally considered costly and a nuisance. But as we have just seen, it is a necessary nuisance. The goal for most companies should be to do the best job testing possible and to minimize the costs. The idea that seems to work best is "test early and test often." Robustness isn't a module that can be bolted onto the side of a preexisting system -- it is far more cost-effective to develop robust software if you strive for this quality from day one. Similarly, the more software is tested, the more bugs will be found (although bad test strategies are often ineffective ones). John Viega and John McManus John Viega is a Senior Consultant and Research Associate at Reliable Software Technologies (RST) and founding member of the Software Security Group at RST. He can be reached at jviega@rstcorp.com. John W. McManus is the Director of Research at Reliable Software Technologies. His research interests include object-oriented software design and development, real-time simulation, and concurrent systems design and analysis. He can be reached at jmcmanus@rstcorp.com. <><><><><><><><><><><><><><><><><><><><><><><><><><><> WHAT PROGRAMMERS COULD LEARN FROM WRITERS <><><><><><><><><><><><><><><><><><><><><><><><><><><> Recently, while shuffling my office library from old bookshelves to new, I came across an almost forgotten book about software development. Published in 1979 by Microsoft Press, Programmers at Work borrows a metaphorical page from the Paris Review series Writers at Work. Reading most of the Paris Review interviews was part of my education as a writer. The interviews demystify the process of creation; writers discuss the genesis of a work of poetry or fiction, why they wanted to be writers in the first place, whether they write with a pencil, typewriter, or pen. Most, I learned, keep regular working hours, writing whether they feel inspired or not. Hemingway usually wrote standing up, balancing his typewriter on top of a bookcase. Gore Vidal reports his workday begins with "coffee and a bowel movement. Then I am visited by the Muse." Looking over Programmers at Work, I was again struck by the similarities of the mostly solitary work of creating program code and writing poetry or prose. In Programmers at Work, Charles Simonyi ruminates on whether programming is art, science, or craft. Bill Gates and Jef Raskin discuss the future of software, operating systems, and user interfaces. And a lunch-hour pizza, I learned, inspired Pac-Man. I recently celebrated my silver anniversary as a writer; conversely, I have been an IT professional for only 15 years. As an undergraduate, I majored in the liberal arts, where, contrary to urban legend, we were not instructed how to say, "You want fries with that?" We learned to write quickly and accurately, and above all, how to think on our feet -- or on our typewriters. Our journalism exams usually consisted of being given raw material (wire-service copy, notes, snippets of film or videotape) from which we were required to produce broadcast-quality copy within a rigid time frame. Near the deadline, the professor, who had obviously learned from the real world of network news, would burst into the room, waving some wire copy and a reel of film, shouting, "News flash! News flash! The Prime Minister of Chumbawumba has just been assassinated! There are tanks in the streets and rumors of a coup...." Broadcast deadlines were, the lesson reminded us, inviolable and absolutely nonnegotiable. Daunted, we rearranged our newscasts for the updated Big Story. Often, after we had incorporated the Chumbawumba coup into our lineup and seconds before the deadline, he would return, shouting "Bulletin from the National Weather Service -- chance of a blizzard tonight!" With our final minutes, we had to decide how and when to incorporate the possible blizzard, whether to save it for the weather forecast or lead with the possibility of a disastrous snowstorm. Never have I heard a software instructor (except me) assign a task to a group of students, and near the deadline for the exercise, return to the room screeching "Stop what you're doing. We just got a new requirement from marketing!" It doesn't happen in the classroom very often, but it happens all too often in the real world. Another disturbing dissimilarity I have noted is that writers learn from carefully studying the works of others and, later, having one's own work dissected. The exhaustive line-by-line examinations of my student essays and the works of Byron, Joyce, and Melville were never repeated to the same degree in the software world. Some organizations encourage or enforce walkthroughs and reviews, but all too few do so as a matter of course. But the most important lesson I learned as a writer was that one becomes a writer by writing: words and more words and still more, then throwing it all away and writing again. Balzac, I believe, said that one does not become a writer until he has written and discarded a million words. I served this apprenticeship early on, writing my first million words before age 16, and only later being paid to write. Conversely, some of the first lines of code I wrote 15 years ago are still in production. Programmers at Work was intended to be an ongoing series, as Writers at Work is today. Sadly, only one volume was published. Apparently, the software industry did not share Microsoft Press's enthusiasm for analysis and unhurried reflection. Instead, we write millions of lines of throwaway code and, without reflection, place it into production. Jeff Gainer Jeff Gainer is a software process management consultant and writer. His management and technical articles have appeared in Cutter IT Journal, Enterprise Development, Contract Professional, and Visual Basic Programmer's Journal. He can be reached at gainerj@jeffgainer.com or on the Web at http://www.jeffgainer.com . Mr. Gainer lives in Grand Junction, Colorado, where he is reportedly stockpiling champagne. |