Home 
CM Journal Articles Dimensions of SCM Challenge #2
CM Journal Articles Dimensions of SCM Challenge #2
|
 Standards and Interfaces & Requirements or Business
DemandsPart of managing software development is dealing with the challenges that arise. Delivering software requires overcoming the challenges, or at least mitigating the attendant risks during the development activity. Generally, organizations work with a constant level of challenge. When one challenge is overcome, the organization will take on a new challenge. For example, when a project releases software that overcomes a technical challenge, it might then schedule a new release with a challenging timeline, or re-open the technical challenge by choosing a new target platform. The next challenge is not "just like the last one, only more." An organization that successfully implements geographically distributed development does not follow up by adding another development office. The organization may well open another office, but doing so is now a normal operation; in order to maintain the level of challenge, some other "impossible task" must be undertaken. While problems may have unique characteristics, there are a lot of common themes. This series discusses sixteen separate dimensions of challenge. The situation your team faces can be analyzed with respect to the dimensions listed here, and some appropriate conclusions drawn. Each dimension is dissected, and some approaches for dealing with it are provided. Here is the complete list:
Dimension: Standards and Interfaces For our purposes, there is not much difference between a standard and an interface. Either one can be nearly trivial to support, or can impose enormous costs on the project. Complying with an internal coding standard, an ISO language standard, or a database vendor API can be simplicity itself. Trying to conform to a certain process model, or interface with a complex file format or communications protocol can supply problems for years. Part of this stems from the amount of documentation available for the standard or interface. Abundant documentation usually correlates with a straightforward implementation, especially if the documentation comes from O'Reilly & Associates. When the standard or interface is a moving target you can generally anticipate problems, but anticipating the problems usually helps mitigate them. Sometimes the interface is all but undocumented. Every significant release of a major web browser is accompanied by a flurry of Internet activity dedicated to researching and understanding all the bugs and quirks in the rendering engine, and a parallel search for ways to uniquely identify the new version from within CSS, within HTML, and using Javascript. If you work for a popular web site or a maker of web design technology, or if your organization specializes in web design, then keeping abreast of these updates is crucial to your business. (If you've never dealt with the joys of browser detection, ask a co-worker or friend who has. Once you get them started, the stream of bile and frustration that emerges will curl your hair.) Working with an undocumented interface that is crucial to your product but totally outside your control is one extreme form of challenge. That particular challenge is usually short-lived, since everyone else in the web industry begins exploring and documenting the browser quirks at the same time. Another kind of challenge happens when you are implementing a standard without any specification of the required outcome. While an open specification works well for requirements, it doesn't work when different teams interpret the same prose to mean different things in the design. If each side of an interface expects the other side to handle object initialization, for instance, then the first integration test will be short, loud, and exciting. One key ‘gotcha' to beware of when dealing with a technical standard or interface is the need to explore these standards very early in the process. Even when you are ‘assured' of documentation or technical details, there are often subtle dependencies on the ‘usual' values or the order of certain items. For instance, a generic "set parameter" interface may actually require that parameter A always be set before parameter B. If your project doesn't control both sides of the interface, you should allocate time early on to mapping out the context and expectations. Interface Management is a defined part of configuration management. Sadly, few software shops have much (if any) experience formally managing interfaces. There is a technique, Formal Interfaces & Standards, that uses the constraints and rigidity of interfaces as a strength rather than dealing with them as a challenge. This is a question of choice-the technique relies on using interfaces that you choose to put in place, rather than externally-imposed constraints. In fact, once you have agreed to use a standard, it doesn't matter how it came to be. Having voluntarily agreed to the constraints may make the situation more palatable, but the concrete challenges will be the ones listed above. The lifespan of a standard or interface is one of the most important factors in determining the inconvenience it will cause. A long-lasting standard or interface will generally be better documented, more flexible, and can be incorporated into the requirements, architecture, and design of the product. It is unlikely to change at all, but if it does change it will likely be a minor modification or update. A short-term interface or standard will generally be seen only at the design phase and after. It may be modified, updated, or it may disappear entirely between one release and the next. For example, a "supported operating systems" list is a long term constraint, with updates as new OS versions are released, and a gradual phasing out of old versions. (Current-day Windows applications support surprisingly old versions of Windows, going as far back as 98 or ME.) A decision to support a particular version or release of Oracle might qualify as either a long- or short-term constraint. If the Oracle software is being bundled with the product, or is expected to be installed on a dedicated server for the product, then the required Oracle version can be changed in lockstep with new product releases (usually with a small fudge-factor for upgrades). But if the Oracle installation is expected to be part of a customer's existing infrastructure then the range of versions supported will be much wider, and testing will need to be much more thorough. Finally, if an interface is completely internal to the product-a gateway between two modules, or a file format-it is likely to be entirely under control of the respective development groups, and so can be changed from version to version. In this case, the only limiting factor is the agreement of the various teams that use the interface. This is no small thing, since some of the other dimensions of challenge can rear their ugly heads at this point. Using Formal Interfaces & Standards is a good way to isolate development teams that are divided by geography, language, culture, or politics. But using the technique transfers part of the challenge directly from those dimensions to this one-a geography or culture challenge is transformed into a standards conformance challenge. Using interfaces is a boolean proposition: either the system correctly uses the interface, or it does not. (Which is not to suggest that all interfaces are simple!) This is normally determined as part of system testing. Standards are less sanguine. Some standards, like programming language syntax, can be verified mechanically. Others have to be enforced or checked using a higher level process. In some cases, like with a process standard, the higher level process is necessary just to implement the standard, and so an even higher level process is required for checking. Checking for conformance can sometimes be implemented either manually or with an automated process. The choice between automation and manual effort may be a property of the standard, or it may be a cost-based or effort-based decision. Opting to spend thousands of man-hours a few at a time in a manual process over months or years instead of spending tens or hundreds of man-hours automating a process is a management decision-frequently a surprising one. The decomposition-based construction techniques (Component-based Development, Service-oriented Architecture, and Software Assembly) are all potentially useful, provided that the decomposition aligns with the interfaces and that the interfaces are at roughly the same level as the granularity of the decompositions. It makes no sense to try to break up a complex library in order to align it with a special memory allocation package. When dealing with standards, rather than interfaces, decomposition won't provide any direct benefits. In this case, Software Product Lines might be useful if the standard can be viewed as a feature-that is, if the standard is not an all-or-nothing proposition but instead constrains a subset of the product, or can be presented as an optional element. Many programs offer installation options to select one or more languages or character sets for the user interface or for program data. If conformance to an accessibility standard were an installation option, SPL would be a useful approach. Similarly, if the standard in question is a technical standard like support for a particular file format or graphics engine then SPL may be a good fit. The Microsoft OfficeTM suite installation process used to offer file format translators for a slew of competing products as optional packages. An organization converting from another word processor or spreadsheet package could install the readers for those file formats, while other customers could save the disk space. Of the organizational techniques, System Architect has relatively little to offer. Using a Change Control Board can be an effective way to manage changes to an interface or standard, since the board will likely be small enough to work effectively together but diverse enough to consider all the likely impacts of a change. The makeup of the board will dictate its effectiveness dealing with interfaces or standards. A board that is represented along political/organizational lines (1 seat for QA, 1 seat for IT, 1 seat for Development, etc.) will handle process standards well, but will likely not do well for technical interfaces. Conversely, a board broken down along functional lines (1 seat for electrical, 1 seat for sensors, 1 seat for control systems) will do well managing technical interfaces but may not fully grasp the nuances of a process standard. Having a Subject Matter Expert can be an effective way to deal with a standard or interface, provided the SME is expert in the standard. When the interface or standard is key to the project, a SME is nearly always a good solution. Technical standards and interfaces generally don't interact with the work flow techniques. Process standards are another story. Project Baseline is likely to be the SCM technique envisioned by the authors, designers, and implementers of nearly all process standards. As a result, using Project Baseline is likely to minimize the problems encountered when first adopting a process standard. Problematically, not all projects can use Project Baseline, especially not with recent process standards like ITIL. Longacre Deployment ManagementTM bridges between the Project Baseline and ITIL styles, and can provide enough of an "adapter" to help complex projects conform to common, consistent standards. The codevelopment techniques can be useful with technical standards (as opposed to process standards) and with most interfaces. Independent Development Paths created at the right level can permit a group of developers to make changes to an interface without blowing up the development environment for the rest of the team. Likewise, Distributed CM lets separate teams work separately. If the organizational structure is aligned with the interface structure, this will help keep both sides of the interface(s) separate, but bring their work together for integration in a controlled manner. Finally there is Formal Interfaces & Standards. Recommending this as a response to Interface challenges seems a bit of a bromide-"when life gives you interfaces, make interface-ade"-but it works. For technical standards, fighting one interface problem with another interface is a straightforward Facade pattern, or an Abstraction Layer. Standards conformance is a ceremonious activitity, and all of the ceremonious techniques are potentially useful. Requirements Management can help with high-level technical standards, and with low- and mid-level process standards. (Low-level technical standards tend to disappear behind a single requirement, which isn't very useful. And high-level process standards usually control the process of implementing the requirements-they are too high level for requirements to be useful.) Automated Enforcement of Standards is pretty much a no-brainer, provided the standards are amenable to being enforced automatically. Treating interfaces separately, and using a tool like IDL or rpcgen to manage them fits into this category. AES is not restricted only to process standards. Lastly, Gated Workflow can help with process standards and human-centric technical standards by forcing the standards verification to take place early in the change life cycle. As an example, certain software controlling the administration of drugs is required by the FDA to be peer reviewed whenever a change is made. Inserting this peer review sign-off into the change request work flow is an effective solution to the constraint Dimension: Requirements or Business Demands Changing or unknown requirements can be a huge source of problems for a development team. Fortunately, configuration management is designed to support exactly this development problem. Books and tools abound that address the issues of managing changes, documenting and tracing requirements, and ensuring that the true needs of the eventual customers are met by the project. Requirements elicitation and elucidation, change management, and traceability tools are all available in the commercial market, and Agile development methods can ensure that customer representatives are involved from the very beginning. Tracking changes to requirements is not the same as tracking changes to software, but nearly every CM tool vendor offers an extension or plug-in for requirements management. Similarly, the requirements management tool vendors offer change tracking systems, as well as integrations with CM tools. The most basic requirements challenge is knowing that a requirement exists at all. When a project transitions from a "clever idea" to a formal product, or switches from development to maintenance, the developer(s) will begin to get change requests and feature suggestions from a multitude of new sources. Keeping track of the ideas, and which ones are approved, is an important first step. Frequently this is implemented using the team's change tracking tool. As the difference between requirements and change requests becomes more clear, the team can move to Formal Requirements Management. The next source of requirements challenge is simple: a requirement to do something really, really hard. There isn't much that CM can do to help directly with this kind of requirement. A good requirements management tool will, however, be able to predict the impact of the requirement-which parts of the project are affected by the requirement, and so likely to change. In some cases a single difficult requirement is really a Technical Complexity challenge (solve the Traveling Salesman problem), or a Technological Diversity challenge (integrate with a decades-old legacy system), rather than a requirements challenge. Please refer to the appropriate article, when they come out. One common form of the "hard to do" problem is a requirement that the development team has never faced before. If a team that is accustomed to performance requirements is suddenly faced with a peak power requirement, for example, the team may get "stuck" with little or no idea of how to proceed. This may genuinely be a hard problem, but more likely is that the solution already exists. The solution in this case may be a new technology, especially if the requirement is being driven by managerial enthusiasm. Beware of hearing "this is the new state of the art" in meetings, and expect to deal with Technological Diversity challenges. When a team is facing an entirely new category of requirement, Subject Matter Expert is a good bet for a solution. Another source of heretofore-unseen requirements is organizational change. When an organization is being divided, or when two organizations are being merged, some new and strange requirements can appear. ("Integrate our product with that other product over there. Make it seamless!") Beware of other Organizational Structure challenges, obviously. Sending an envoy from one team to another makes sense as a basic Subject Matter Expert approach, but identifying someone to be sent to another team can also identify them as a target for layoffs-there aren't a lot of easy answers. When the challenge stems from the number of requirements, the complexity of the requirements, or from the need to verify the requirements, the answer is going to be Requirements Management. (It seems a little shady to be classifying an entire discipline as a CM technique, but this isn't a requirements management journal.) CM tool vendors have a variety of requirements management solutions already available, and the biggest tool vendors-Rational (now IBM) and Telelogic (now IBM)-offer requirements management tools that integrate with their CM tools. (DOORS famously integrates with nearly everything.) The last source of requirements challenges, and the most common, is frequency of change. When requirements changes (including new requirements) occur too fast, the development team can't keep up. Symptoms include the reappearance of defects or deviations that have been fixed, excessive trouble testing the product, problem reports citing recently-updated requirements, and customer complaints about unresponsive or inadequate development. If the requirements change cycle is significantly faster than the development cycle, the list of pending changes can grow ridiculous. When this happens, development may respond by asking for an incredibly long requirements change and review cycle, typically tied to the development cycle. This is a symptom, and the solution is to speed up the release cycle, not slow down everything else. Consider an Agile development approach, in order to tighten up the feedback from development to customers. The organizational techniques can be tremendously valuable when dealing with requirements challenges. A Change Control Board is an excellent source of detailed analysis when composed correctly. If you already have a CCB that you fear might be wrongly constructed, consider creating an additional one within the development group(s) with the right make-up. The ‘correct' composition will depend on the type of requirements that are presenting the challenge. Functional requirements will need a functional CCB, procedural requirements need an organizational or managerial CCB. The benefit here is that each member of the board is looking at changes from the point of view of their own area of expertise. Parochialism is a benefit, since proposed requirements and proposed implementations can be checked in some detail. System Architect does not offer the same diversity of interests that a CCB does. However, a single person with the entire system in his head provides a different value. The System Architect is going to have a strong grasp of how the different parts of the system interact. In combination with a construction technique like Component-based Development or Service-oriented Architecture, the architect can review and analyze a larger volume of system changes than a CCB. When rate of change is the primary source of challenge, System Architect is a good technique for dealing with technical requirements. In fact, a System Architect is essentially a specialized Subject Matter Expert in the context of requirements challenges. While a System Architect offers quick, informed understanding of technical requirements changes, a Subject Matter Expert can be created or hired for any kind of requirements challenge. This makes Subject Matter Expert the organizational technique of choice for rate-of-change challenges. Unfortunately, it can take months for a SME to get up to speed on a technical project. The particular nuances of a long-standing project take time to learn. Obviously the actual time required will be different for each separate aspect of the project. A DBA may come along quickly for table & index performance issues, but then take months to comprehend all the triggers and stored procedures that are used. Keep in mind that Subject Matter Experts are not strictly technical. There are plenty of experts available for process, management, and business requirements. (This is a shameless plug: the author is one of those available experts!) The codevelopment techniques are useful to address rate-of-flow challenges. Simultaneous Development is an obvious requisite. There are occasionally situations (usually involving a common file or table) where serialized development is put forward as a solution to rate-of-flow challenges. It is better to make a simple process change to deal with this-choose one official maintainer of the file or table in question and assign all changes to that item to the designated victim. You may have to create "child" requests or tasks for this, but it is simpler and more effective to give all the funny stuff to one expert. Of the ceremonious techniques, Automated Enforcement of Standards and Gated Workflow can help with requirements challenges when they are used in conjunction with other techniques. The object with these techniques is to devise a process that will help with requirements challenges, and then automate it. Obviously, Automated Enforcement of Standards is a win if the standard is one of the requirements. But it can also be used to execute test cases, which ties in nicely with Fast Feedback on Changes. Similarly, Gated Workflow can be used to involve a SME or CCB in the process, requiring sign-off before changes enter development. Gated Workflow can also help ensure that regression testing or impact analysis are done after a change is delivered. Finally, Requirements Management is a strong technique to use with rate-of-flow challenges. If a requirement is just unfamiliar, or merely incredibly difficult to implement, then requirements management may not offer much benefit. When a large number of requirements are changing, or when they are constraining the response to a smaller set of changing requirements, Requirements Management is the way to go. Looking Ahead I'll try to cover two new dimensions of challenge each month, but there's no fixed order. If you have a particular issue you'd like to see discussed earlier, drop me a line. If you have a challenge that I haven't identified, please, please let me know-I don't claim the list is exhaustive. Austin Hastings has spent more than 20 years in the software industry. He has been a developer, system administrator, CM specialist, manager and consultant. Currently he is principal consultant for Longacre, a software CM and process automation consultancy. Austin lives in the southern part of New Jersey (the garden of the Garden State) but travels the world helping to keep software under control. Contact him at Austin_Hastings@Yahoo.com, or through CM Crossroads.
Set as favorite
Bookmark
Email this
Hits: 4717 Trackback(0)Comments (1)
|
TrackBack URI for this entry
Subscribe to this comment's feed
 |
... The discussion dealing with all dimensions is really the first approach I have seen to determine the real scope and challange of CM. Important is that no subject or discipline can be understood if one do not have an holistic view first and go into detail later. In order to manufacture cars it is not enough to master car construction.One needs to master car manufacturing! As CM in order to run a CM operation one needs to master the holistic view first and details second and as holistic views selldom is hoasted together with details in one human brain this is difficult. One thing mentioned is also one seldom understod role as system architect as that role too must master not only the actual tasks but also the manufacturing as well. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
