configuration management
Articles
|
The Trouble with Tracing: Traceability Dissected Traceability! Some crave it. others cringe at the very mention of it. For hardcore configuration managers and requirements and systems engineers, it is a fundamental commandment of “responsible” software development. For many hardcore agilists and other developers, the very word evokes a strong “gag” reflex, along with feelings of pain and frustration. Traceability requires work and discipline! So how does traceability add value to our business and how can we make it easier? |
||
|
Consistent Quality Requires Consistent Processes It was a restaurant my wife and I had passed many times, and we had always told each other, "We must try them some day." When we finally tried them, we were pleasantly surprised. The food, the service, the atmosphere, even the price were great! "This will be a regular stop for us," we agreed. But on our third visit, we had to send our food back twice. Another time, we waited nearly an hour for our order. Then, some time later, we were seated at a table that was not clean. Most of the time, things were great. But as we experienced sporadic problems, we visited that place less and less often. |
Alan S. Koch
November 30, 2005 |
|
|
To Branch or Not To Branch (and Merge/Test) I don't like merging. When I merge I've got to retest. This is especially difficult if the merging occurs a few days/weeks after the original change. Come to think of it, I don't really like branching, but that depends. Do I have to merge whenever I branch? Do I use branching for a specific discipline or is it a catch-all operation which gives me all sorts of capabilities in return for a spaghetti-like spider web of branches and merges? What about all the labeling that goes with it? There must be a better way, a way to reduce branching, and merging, while increasing automation and reducing complexity. What is it? |
||
|
Building a Configuration Management (CM) Capability for Test
As more test items exist, there is a tendency for them to evolve due to the changes to requirements and code and, therefore, must be managed effectively. When there are an increasing number of test items, this increases the risk of failing to accurately track all test items, particularly when this is done manually. This is where configuration management (CM) can help.
|
||
|
The Journey Through Traceability to Process Control Taking a team from an undisciplined product development strategy, through an organized process with visible tracks, to a mostly automated, self-improving process is a long journey. It requires a good understanding of change, an adequate SCM tool or tool suite, good people for sure, and a lot of common sense. The journey is well worth the effort, though. I've been down the road more than once. It leads you to the path where you can manage properly and let the configuration management be handled automatically. |
||
|
Automating CM or Application Lifecycle Management Automation is at the heart of excellence in the field of configuration management. Unless a wider definition of CM is used, that of application lifecycle management, automation will fall far short of the mark. As we enter this still young millennium and look back at the progress of CM, it's clear that the industry has, for the most part, been creating tools to fight fires and to avoid them. Spot solutions originally dealing with version control, change management, problem/issue/defect tracking, etc., have given way to more integration. Yet as a whole, the industry has fallen far short of the mark required for CM, or ALM, automation. |
||
|
Requirements Driven Development: A Stream-Based WBS Approach Requirements are a must have. Or should have. Maybe a want. OK, maybe not really requirements. When it comes down to it, you need to understand why you're building what you're building in sufficient detail so that you will know if what you built does the job. You also need full traceability to show that you have met the requirements. Developers work to a set of requirements, but these are not the same as the product requirements, which are again different from the customers' requirements. And what about ad hoc requests? Where do they fit in? |
||
|
Avoid Role Name Confusion Don't you find it confusing when you go from one company to another and find all sorts of different names for similar roles people play in the IT software development process? I have had heated debates with people only to find we were in violent agreement and it was the use of different terminology that was causing the incorrect interpretation, because we were ultimately both trying to say the same thing. This doesn't only happen with roles and activities on projects but with many different terminologies meaning the same thing!
|
Charles Edwards
November 29, 2005 |
|
|
Integrating Developer Tools: Intuition vs. Reality While many people intuitively feel that we should integrate the development tools we use in our software development environment to better manage the development team, the task of actually doing so can sometimes be as big if not bigger than the software project we are trying to develop. It's hard enough trying to implement individual software development tools while you are in the throes of building software, let alone get multiple sets of these tools to start synchronizing and talking to one another. |
Charles Edwards
November 29, 2005 |
|
|
Enterprises Need Higher Level Process Frameworks for Better Control Enterprise application integration (EAI) is problem many large organizations facie today. With the emphasis on the integration part of the applications within the enterprise, more recently made even more complex by integrating applications outside of the enterprise. There are business engineering approaches can alleviate many of these problems and have in particular organizations. |
Charles Edwards
November 29, 2005 |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.