Methods & Tools - News, Facts & Comments Edition - May 2001

*** Products ************************************************************

* More Free UML Tools

Our article from the last issue has provoked some reactions from readers... and tools editors... :-] Here are some additional Web sites where you will be able to find free or trial versions of UML tools. To be continued?

First we misspelled in the April issue the URL for free Argo UML java-based tool. The correct Web site address is: http://www.argouml.org

www.nomagic.com/magicdrawuml/ - java based, limited demo version, 15M

www.arctaedius.com/ObjectPlant/ - free for McIntosh, 2.7M

www.proxysource.com/ - free, 2.3M

objectclub.esm.co.jp/Jude/jude-e.html - free, java based, 1M

home.hetnet.nl/~xvenemaj/ClassBuilder.htm - free, C++ focused, 1.2M

www.metamill.com - 30 days evaluation version, 1.4M

 

*** Companies ***********************************************************

* The End of Informix (As We Know It...)

At the end of April, Informix has agreed to sell its database division to IBM for $ 1 billion. Database was the core business of Informix, making up 85 percent of its revenues. The company will be renamed Ascential Software and will focus on the information intelligence business. This is a strange story because Informix acquired this business with Ardent at the beginning of 2000. Following bad results, Ardent executives took the control of Informix at the end of 2000. Now they have sold the database business and it is like they are back to their previous situation... except that they have now a war chest of $ 1 billion to develop their business... :-]

For its money, IBM will get 100'000 Informix database customers, doubling its installed base. The long-term plans are to migrate these customers to the DB2 product line and to integrate some of Informix technology. If everything goes right, this will be good for the development industry, as Oracle's domination will be tempered by IBM's extended presence.

The database business is now a mature sector. The days are far away when Oracle, Sybase, Informix, IBM, Microsoft, Ingres and OO start-ups where battling for the number one spot. Oracle is a clear winner in the large database market. Even if the business is mature, it does not mean that it is not interesting. Database has become infrastructure software as common (and fundamental) as file management. Database's presence creates contacts to sell other applications and to benefit from the success of competitors; many SAP users have an Oracle database for instance.

*** In Other's Words ****************************************************

* Organization or Process?

"Software development organizations face an array of process standards, with ISO 9000-3, ISO 15504, and several flavors of Capability Maturity Models among the most prominent. Are all of these standards equally effective, or do some provide better guidance for process improvement? Why do some organizations with development processes 'certified' under one or another of these standards still suffer delivery and quality problems?

The answer to the latter question is that improving your process is not enough - you must change your organization. The benefits from implementing a process standard may prove elusive if an organization's most dysfunctional traits are allowed to undermine new practices. Mandating quality practices is often not sufficient to produce quality results. Improved processes must be nourished in an organizational culture that perceives them as a logical implementation of its professional values.

Too many organizations use a process standard as a checklist rather than as a guidebook. The checklist mentality emerges from a belief that software processes are performed to gain certification rather to improve project results. Too often, organizations driven by checklists implement practices mechanistically. Mechanistic processes may not be continuously integrated and improved since they are treated as actions to be checked off rather than as coordinated tasks that produce quality software.

Improved practices are perpetually at risk if an organization's commitment to them ended at certification - they will erode rapidly if abandoned under stress or ignored by a new management team. Circumventing software processes is akin to telling a commercial pilot, 'Don't tell me about your stupid procedures - just get this plane in the air!'. Managers and executives with this attitude lack a mental model of software development wherein software processes are causally linked to project outcomes. Such managers do not appreciate

- the level of process coordination required to build complex software products

- software development as a professional discipline, or

- the importance of an organizational culture in sustaining professional practices.

To ensure that your organization will maintain a professional software engineering discipline, you must build it into the culture. Organizations that use a process standard as a guide for developing a professional software engineering culture will more likely achieve sustainable gains in their performance. In addition, a strong culture supports new engineers and managers in developing both skill and faith in the existing processes.

Why is a professional culture important? Put simply, a process standard cannot anticipate all the practices or decisions that must be applied in a specific project to achieve quality or productivity goals. It is the professional discipline in the culture that orients developers to add, modify, improve, or improvise practices that are not required by a standard but are nonetheless necessary to achieve project objectives. In the absence of such a culture, an organization may comply with the specific provisions of a process standard but fail to interpret the standard into a system of processes that achieve either the standard's purpose or the organization's objectives.

A professional culture treats a process standard as a product of community learning that it need not reinvent. Such cultures focus on using and tailoring process standards rather than rigidly (and perhaps resentfully) adhering to them. Project managers and software engineers develop more quickly when the culture illuminates and rewards standards of professional behavior.

[...] How does an organization build a professional culture from the hodgepodge of cultural fragments it begins with? First, establish core beliefs or principles that will support the implementation of professional practices. These beliefs must come from the organization's executives. Not suprisingly, lack of executive support is the single biggest reason that improvement programs fail. When assigning blame for failed improvement initiatives, start at the top.

However, proclamations from the summit are not enough to change an organization's culture. Those who manage day-to-day activities must transform organizational values into expectations, for behavior, then hold their groups accountable for compliance. Thus, process improvement logically starts with management, since management controls the mechanisms for changing the culture.

For an improvement program to thrive, its first actions must change or eliminate the organization's most dysfunctional behaviors - those that pose the greatest risks for successfully installing other improvements. Thus, the first wave of process changes should collectively establish a management framework within which professional practices can thrive. Without a strong project management framework, improved processes will not survive the next outrageous schedule commitment or the continual sacking of requirements. Strong leadership and management prepare and protect the fertile organizational milieu within which a professional culture can develop.

[...] However, culture can stagnate. Only continual vigilance in measuring and improving processes can ensure that the organization maintains its professional vitality amidst tidal changes in technology and business competition. A process standard should ultimately motivate organizations to establish mechanisms for continual improvement."

Source: Bill Curtis, "Which Comes First, the Organization or Its Processes?", IEEE Software, November/December 1998

The wave of standard certification is today less strong today than in 1998, but they are still projects to improve the software development process. Avoiding the checklist mentality is a crucial success factor, but building a professional culture ( and one that recognises that failure happens...) is not an easy task!