Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

 

Methods & Tools - News, Facts & Comments Edition - October 2003

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

* Brave New Linux World

We have seen recently a wave of cooperation announcements between hardware suppliers and companies active in the Linux area. Novell acquired Ximian to expand its Linux solutions. Sun and SuSE Linux entered a global alliance. SuSE will distribute Sun's Java Virtual Machine and Sun will sell and provide full customer support for SuSE Linux Enterprise Server 8 on Sun's systems. Deals of similar nature were concluded between SuSE and HP or Red Hat and Bull.

As Linux seems to make its way into the commercial world of software development, this could not leave Microsoft without voice. At the beginning of September, Microsoft published the results of a study named "The Total Economic Impact of Developing and Deploying Applications on Microsoft and J2EE/Linux Platforms". Giga Research, a subsidiary of Forrester Research, conducted this study. The conclusion is that "Microsoft offers a substantial cost advantage over J2EE/Linux as a development platform for the applications considered".

The fact that this research was commissioned by Microsoft allows raising some questions about the true independence and the impartiality of the results. Even without the suspicion that the approach could have been biased, comparing software development projects between different organisations and technologies is a matter that should be taken with prudence before reaching definitive conclusions. My limited statistical knowledge tells me that basing a study on only 12 organisations (7 for .NET and for 5 Linux) should lead us to interpret results with even more caution. At least this seems to show that Microsoft is seriously considering the threat provided by Linux and other initiatives linked to the Open Source movement.

If you want to have your own opinion about this topic, the PDF file containing the research commissioned by Microsoft is available on its web site:

http://download.microsoft.com/download/7/3/e/73e77129-db34-4c95-b182-ab0b9bd50081/TEICaseStudy.pdf

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

* A New European Software House

At the end of September, Atos Origin announced that it will acquire the core IT services activities of SchlumbergerSema from Schlumberger for a price of 1.287 billion in stock. The combined organisations will have revenues of more than 5 billion and a workforce of 50'000 employees. From the Sema Group, Schlumberger will keep the US telecom software activities (LHS), Infodata (databases) and the IT activities dedicated to the oil and gas sector. As part of the deal, Schlumberger entered into an IT services agreement with Atos Origin with minimum revenues of US$ 700 million.

Schlumberger acquired Sema in March 2001 for US$ 5.2 billion. The Anglo-French group was in trouble after the acquisition of LHS for $ 4.7 billion in March 2000 at the climax of the technology bubble. Atos Origin was created in 2000 by the merger of French group Atos with Dutch Origin, the IT services arm of Philips, whose shareholding in the new entity will be 32%.

This is another acquisition for Atos Origin that already bought last year the UK and Netherlands organisations of KPMG Consulting. Even with the important outsourcing contract, it is not sure that the deal will be beneficial for Atos. Sema morale is considered pretty low, as the last years have been difficult and full of changes. Moreover, even with a third place on the European market, Atos Origin still lacks US presence to be a global competitor. Some analysts already think that it could be acquired in a near future.

This deal also reveals the failure of Schlumberger to integrate Sema. The rationale of the deal was to integrate "hardware" and "software" organisations to differentiate industrial products and services. Other industrial companies like ABB followed this trend, but it seems to have not produced any significant results.

*** Numbers ************************************************************

* Microsoft's Discount Offer

Here are some extracts from the study commissioned by Microsoft to compare development with the .NET and J2EE/Linux platforms

"The study indicates that the economics of Linux depend on the larger IT context for the operating system. (The same is true for open source software in general.) In a head-to-head comparison, the list price for Red Hat Enterprise Linux and Red Hat 9 (the Linux version chosen for this study) is less expensive than Microsoft Windows Server 2003. However, the key cost factor in the study's Linux cases was the J2EE environment, not the operating system. Although the cost of Linux is low, the impact of that lower cost on the overall economics of an application development project is minor. The full development and deployment environment and the labor associated with the development project are the biggest costs. Comparisons of individual elements within the stack of software products required to build and deploy a complete application tell only part of the story."

"The comparison of the two platforms shows that large to medium-size organizations that develop, deploy, support and maintain custom applications on the Microsoft .NET platform can expect to experience 25 percent to 28 percent less cost during a four-year life cycle than if the J2EE/Linux platform was used."

"Giga found that for the large sample organization, the total costs associated with the initial development and deployment, plus three years of support and maintenance, were $645,929 less using the Microsoft platform. Microsoft's total costs were 28.2 percent less than the total costs for J2EE/Linux. The primary driver of this difference is a shorter time to deployment for Microsoft - nine months vs. 12 months for J2EE/Linux."

Source: "The Total Economic Impact of Developing and Deploying Applications on Microsoft and J2EE/Linux Platforms", Forrester Research, Inc.

Here are some explanations why Microsoft is a cheaper solution. It appears that the problem has nothing to do with the price of Linux, but mainly with the software and effort used for development. However mixing Linux and J2EE in the title of this research seems to offer Microsoft the opportunity to kill two birds with one stone.

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

* Successful Software Measurement

It's not about the metrics

[...] measurement is not an end in itself; it's a vehicle for highlighting activities and products that you, your project team, and your organization value so you can reach your goals. But it's only a tool. To get anywhere, you must navigate the road - you've got to make decisions and act.

To create an effective measurement program, you first must understand exactly where you want to go or what you want to accomplish; that is the "why" of measurement.

Success comes from channeling an organization's pain into action

No matter how much I dislike this secret, I have found it to be so. It comes back to the fact that it's not about metrics; it's about the strength of the motivation to know or improve something and to follow through with action. No matter how noble the intention, "Let's do metrics" just doesn't provide sufficient motivation.

The single biggest determinant of measurement success lies in the answers to the following questions: How badly do you want to know the information, and how will you use it.

Establishing a measurement program is easy: keeping it going is hard

I am continually impressed by how easy it is to think about potentially useful measures and how hard it is to implement an effective measurement program. Within a project or organization, it's often easy to get people enthused about measures - but all too often, that enthusiasm does not translate into action. Even when it does, it is unlikely to be sustained. Getting the numbers is easy; doing something with them is not.

What you need is no less than to change your organization's culture. Cultural change is hard.

People skills matter more than quantitative skills

Every step of the measurement process requires input from the people within the project or organization who will provide and use the data. Emotion plays a strong role, especially at the beginning, leading to a variety of reactions from the individuals involved. Fear that the measures will be misinterpreted or misused can also lead to resistance. Positive and negative reactions accompany any organizational change; anticipating and managing these are necessary.

Senior-level sponsorship and leadership are critical

Although this one might be so obvious that it really shouldn't qualify as a secret, it's absolutely key and often neglected. Remember that it's not about the metrics; its is about articulating a vision and following through with consistent and persistent action. Without these, measurement won't help. The person at the top must participate in the measurement program by

- Articulating organizational goals

- Behaving in ways that are consistent with these goals

- Creating a culture that exposes, rather than hides problems

- Looking at the data and asking questions

- Making decisions and following through with action

- Expecting lower-level managers to do the same

Measuring individuals can be okay

This is probably the most controversial secret. Every source of guidance I've read on measurement advises against measuring individuals. [...]

Let's look first at some counterproductive ways. Punishing people for reporting honest results can quickly data integrity. Organizations with effective measurements programs do punish who hide risks and problems; they don't punish people for exposing them, especially when they also offer solutions. Rewarding one programmer for producing more lines of code per labor hour or punishing someone else for producing less is also inappropriate. That course ignores the fact that code quality and inherent task difficulty vary.

Don't go overboard trying to be perfect

Anyone who has gotten down and dirty with data quickly realizes the importance of understanding what the data represent. Even seemingly straightforward data can be ambiguous. [...] By the same token, keep in mind that "the good is the enemy of the perfect". You must continually balance clarity of definition with the need to get started. In my view, it's best to get started and work to improve the measurement process over time.

Understanding the reasons for variability

in data provides a powerful decision tool

One of the striking characteristics of real data is its huge variation. Look at any graph showing the relationship between size and effort or between size and defects and you'll see a very large spread - so large that these data are typically represented in logarithmic scales. If you can understand what's behind the variation, you'll understand a lot.

Source: Betsy Clark, "Eight Secrets of Software Measurement", IEEE Software, September/October 2002

"You can't control what you can't measure" is a typical consideration of the world of software measurement. There is no "one size fits all" program to achieve this objective, but I think that there is a lot of common sense in the propositions of Betsy Clark.

And maybe some of this stuff could be interesting if you try to compare software projects across the .NET and Linux platforms... ;-)

*** Books **************************************************************

If you liked the article of Sinan Si Alhir in our Fall 2003 issue, find more about his knowledge in the following books:

* Uml in a Nutshell: A Desktop Quick Reference (Nutshell Handbook)

The Unified Modeling Language (UML), for the first time in the history of systems engineering, gives practitioners a common language. This concise quick reference explains how to use each component of the language, including its extension mechanisms and the Object Constraint Language (OCL)

To get more details on this book or buy it on amazon.com click below:

http://www.amazon.com/exec/obidos/ASIN/1565924487/methotools-20

* Guide to Applying the UML

"Guide to Applying the UML" offers a practical bridge between tutorials and reference works, demonstrating how all of the elements of the UML fit together holistically and cohesively. It closes the gap between the UML and process using a "roadmap" that addresses the key decision points and their relationships, providing a comprehensive framework. The focus is on rules of usage and principles of composition, style guidelines, practical real-world examples, and a tool-, process-, and technology-independent roadmap for effectively and successfully applying the UML.

To get more details on this book or buy it on amazon.com click below:

http://www.amazon.com/exec/obidos/ASIN/0387952098/methotools-20

* Learning the UML

Learning UML introduces UML and places it in perspective, then leads you through an orderly progress towards mastery of the language. You'll begin by learning how UML is used to model the structure of a system. Many key UML concepts, especially that of the general (classes) versus the specific (objects), are illustrated in the chapter on class and object diagrams. Next, you'll learn how to use use-case diagrams to model the functionality of a system. Finally, you'll see how component and deployment diagrams are used to model the way in which a system is deployed in a physical environment.

To get more details on this book or buy it on amazon.com click below:

http://www.amazon.com/exec/obidos/ASIN/0596003447/methotools-20

The content of this publication cannot be reproduced without prior written consent of the publisher -
Copyright (c) 2003, Martinig & Associates

April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
November 2009
October 2009
August 2009
May 2009
April 2009
February 2009
January 2009
November 2008
October 2008
August 2008
May 2008
April 2008
February 2008
January 2008
November 2007
October 2007
August 2007
May 2007
April 2007
February 2007
January 2007
November 2006
October 2006
August 2006
May 2006
April 2006
February 2006
January 2006
November 2005
October 2005
August 2005
May 2005
April 2005
February 2005
January 2005
November 2004
October 2004
August 2004
May 2004
April 2004
February 2004
January 2004
November 2003
October 2003
August 2003
May 2003
April 2003
February 2003
January 2003
November 2002
October 2002
May 2002
April 2002
February 2002
January 2002
November 2001
October 2001
May 2001
April 2001
February 2001
January 2001
Winter 2000
Fall 2000

Software Testing
Magazine


The Scrum Expert