The Object Management Group (OMG) has just ended another technical meeting. Usually, these meetings are devoted to committee work on various standards that the OMG is adopting. In this case, however, something rather momentous happened. The OMG has begun the formal process of changing its entire orientation.

Simply put, eXtreme Modeling (XM) is a collection of values, principles, and practices for modeling software. XM addresses the fundamental issue of how you model and document a system in the most effective manner possible. XM is an agile methodology built on the eXtreme Programming (XP) software process.

Simply put, eXtreme Modeling (XM) is a collection of values, principles, and practices for modeling software. XM addresses the fundamental issue of how you model and document a system in the most effective manner possible. XM is an agile methodology built on the eXtreme Programming (XP) software process.

Chances are, you've heard some of these questions echo in the halls of your IT organization -- and for good reason. Size metrics can be very controversial. Whenever the subject arises, it's not unusual for camps to form and for an almost religious-like fervor to engulf the debate. Many fall into the trap of arguing over which metric is "good" and which is "bad." What's better: function points or source lines of code? I'm right! You're wrong! But what about when both sides are right? That's tricky because, indeed, the world is not black and white.

When I conduct a presentation on software measurement, no subject generates more debate than project size. I often describe the Software Engineering Institute's (SEI) core measures of size, time, effort, and defects and find that members of the audience appreciate what the latter three measures are but need to know more about that elusive first metric -- size. Below are eight commonly asked questions on the subject along with responses that might help clarify matters.

The use of software metrics to manage and control project development and delivery is an accepted industry-wide best practice. Even though standardized metric definitions and practices are not yet fully developed, measurement programs are evident in more than 80% of IT organizations today. However, the content and the deployment of these measurement programs vary widely across IT organizations. No IT manager will argue with the adage you can't manage what you don't measure. What is often debated is the effectiveness and usefulness of particular metrics.

"Why do you rob banks?" the infamous criminal Willie Sutton was reportedly asked. "Because that's where the money is," he replied without hesitation. Bankers protect their assets as an obvious and necessary aspect of business. They understand safes, guards, auditing, reconciling cash accounts, two-person controls, and numerous other techniques to secure their money.

The question is not if, but when. Don't question if you will need a computer security strategy; determine when the situation will arise showing you need one. Hackers, criminals, naive users, accidents, tired employees, acts of nature -- all of these can cause serious damage to IT systems and data. Failing to address security can lead to unnecessary risk and expense.

Remote access and virtual private network (VPN) growth continue to accelerate, due to an increasingly mobile work force and the globalization of companies. The rate of growth in these technologies is causing some unique challenges for IT management.

I have been involved with statistical analysis of IT trends since 1989. Gathering and analyzing statistics provides a reality check of actual industry practices against anecdotal evidence, vendor hype, and media hyperbole. The most enjoyable results for me are when the statistics differ so significantly from popular perception that they demand we reconsider our thinking.

The quiet revolution of the Internet and its related technologies continues unabated despite the negative swings in the stock market. Although the hype and hope associated with dot-coms and the new economy have started to fade, make no mistake: the pervasive and profound force of the Internet is very much a part of the real economy, and we ignore the consequences at our peril.

Volume XI, No. 3; March 2001 PDF Version Executive Summary

Volume XI, No. 3; March 2001 PDF Version Executive Summary

Napster, a free application that enables users to trade music with each other at no cost, is the poster child for an evolution of distributed computing architectures, the peer-to-peer architecture. (The recording industry would likely prefer the verb "pirate" to the word "trade" above.) People typically view Napster in one of the following ways:

The Internet is the core technology that drives today's e-business processes. On that foundation sits the Web, one of the most disruptive technologies in the history of business computing. Not more than five or six years ago, businesses looked at the Web with fear and mistrust; after all, it was a technology that connected individuals directly to institutions at any time of the day from any place on earth.

Recently, a well-known methodologist asked me what books or courses I would recommend to those just getting started in component-based development. This shocked me a bit. I've been writing about component development for so long that I tend to think everyone must already know about components. I must realize, of course, that most of my readers are managers or developers working on cutting-edge projects.

The process of creating software has come a long way since the Software Engineering Institute (SEI) was established at Carnegie Mellon University in 1984. SEI was sponsored by the US Department of Defense and given the charter of advancing the practice of software engineering from an ad hoc, labor-intensive activity to a well-managed discipline that is supported by technology.