Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

Methods & Tools - News, Facts & Comments Edition - January 2004

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

* Sun & Eclipse - Episode III: the Breakup

For those who have missed the previous episodes, I will summarise the beginning of this software soap opera.

IBM founded the Eclipse project in 2001 to build an open source software development framework. It financed and performed the majority of the work. This organisation is considered as a competitor to Sun's NetBeans project which had been launched a year earlier. NetBeans was a product bought by Sun in 1999 and originally developed in the Czech Republic. Eclipse of Sun... you know what they mean... ;-) Each project is organised as a consortium of companies. Eclipse regroups 49 members like IBM, Oracle, Borland, Merant, MKS, Red Hat, SAP and others. Besides Sun, the NetBeans side works with Compuware, Objectventure, Novell, BEA Systems and others. Independently from the different platform, another issue between the two consortiums is at the GUI building level with the opposition between Eclipse's Standard Widget Toolkit and JCP-endorsed Abstract Window Toolkit and Swing components.

At the end of 2003 there were negotiations between Sun and Eclipse to merge the two development frameworks, but Sun withdrew from the talks in December because it was not offered "an equitable share in mutual development". At the beginning of January, two new events happen in the saga.

First, Sun formed the Java Tools Community (JCT) with BEA Systems, Oracle and other vendors like Compuware, Embarcadero or SAP. IBM and Borland did not join the JCT. As you can see, JCT is a mix of Eclipse and NetBeans participants. The second event is that Eclipse has decided to incorporate as a non-profit corporation, a move to distance itself from IBM. A non-IBM executive will be named in the coming weeks. IBM is expected to provide less than one eighth of funding for 2004. Members will also contribute developer resources to the open source project. Even if the .NET architecture is still behind Java in market shares, the creation of a consensus about standards from vendors will be a big plus for Java to keep its leadership.

Will Eclipse, NetBeans and the JCT marry and have many plug-ins? See you soon in the future issue of Methods & Tools for the next episodes of this (not so fairy) tale.

Web sites to visit:

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

* Java keeps growing and maintains leadership over .NET

According to a recent study conducted in November by BZ Research, the usage of Java is increasing in companies. In 2003, 72% of the 950 respondents said they were developing with Java versus only 50% in 2002. Java systems were used in production for 55% of the respondents. In a similar study conducted in July, only 17% of the respondents have .NET systems in production and 11% were developing production systems.

Java server ranking:

  • IBM WebSphere 40%
  • BEA WebLogic 35%
  • Oracle App Server 29%

Jboss 27%

Java IDE ranking:

  • Borland Jbuilder 37%
  • IBM WebSphere 35%
  • Oracle JDeveloper 21%

Source: Software Development Times, December 15, 2003,


* M&T February Poll

With the introduction of the Methods & Tools discussion board (see below), I will try to organise some "quick surveys". This time I ask you how you rate the quality of open source software development tools (examples: Eclipse, MySQL, PHP, Junit, etc...) versus the commercial tools.

Go to to express your opinion. The final results will be published in one of our next issue.

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

* Requirements Analysis Skills Revisited

Learn to model

Learn some UML. Learn about human-computer interactions. Practice techniques for problem analysis. Try use cases. [...] Modeling is a critical skill.

Understand your client

Learn as much as you can about his or her business. Mug up on the jargon. Don't be afraid to ask "stupid" questions. [...] Always discuss business objectives before modeling anything.

Think laterally

Requirements engineering is about communication. The only reason you model is to communicate. You use models to communicate with clients and developers, but you also use them to communicate with yourself, to think around a problem.

Guys, get in touch with your feminine side

This does not, I must emphasize, involve wearing size 20 frocks or anything. I merely observe that women often make better requirements engineers. [...] Stereotypically, women are expected to be more attentive to character, emotional motivation, and relationships. They are better listeners. Of course, there are many brilliant male analysts. I generalize only to make you try to become a better, caring, listening, analyst.

Girls, "be a man"

You're already a great listener and you've got all the right technical skills. But if you fit the stereotype, you might be afraid to take over the conversation and get your important idea across. Have an opinion and state it. Learn how to tell the pointlessly pontificating boss to shut up. Use the ten-minute rule: no one can talk for longer without the group's waiver.

Learn a discipline

The best business analysts I have known have had nonvocational degrees. They were not computer scientists, accountants, or engineers. They had qualifications in classics, mathematics, history, music, or physics. As with my other dangerous generalizations, exceptions exist. But it does seem that learning a unified discipline rather than a congeries of techniques changes the way people approach problem solving.

Improve your social skills

Keep in mind, however, that bookworms make poor business analysts if they can't talk. You have to practice communication skills face-to-face with other human beings. I am almost tempted to recommend that neophyte requirements engineers take up serious social drinking. What better way to learn to be a good talker and listener? [...] But you don't want to damage your liver. I wish I could think of another way to achieve the same end. Perhaps you can. [...] Why not join an amateur dramatics group?

Source: Ian Graham, "The Compleat Requirements Analyste", IEEE Software, November/December 2003.

Nice, "back to the basics" recommendations, with the addition of some provocative opinions like the interesting ideas of trying to get our "opposite sex" behaviour involved or spending more time in bars. Cheers! ;-)

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

If you liked the articles of Matt Stephens, Doug Rosenberg and Sinan Si Alhir in our Winter 2003 issue, find more about their knowledge in the following books:

* Extreme Programming Refactored: The Case Against XP

This book wants to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a distinction between true "agility" in a software process and "fragility" inherent in techniques such as oral documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The goals and the good advice draw people in; the bad advice can potentially cause projects to fail. XP therefore represents a high-risk process, wrapped in a "feel-good" methodology.

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

* Use Case Driven Object Modeling with UML : A Practical Approach

The author's approach to software relies heavily on customer requirements and use case scenarios for which he has a good deal of practical advice. He provides numerous hints for avoiding bogged-down diagrams. After preliminary design, he advocates drilling down into specifics with robustness diagrams, which trace how classes interact with one another. The most detailed design work comes next with sequence diagrams. Subsequent chapters offer tips on project management, implementation, and testing.

To get more details on this book or buy it on click below: 0201432897/methotools-20

* Applying Use Case Driven Object Modeling with UML

This workbook is a companion to Use Case Driven Object Modeling with UML. It bridges the gap between the theory presented in the main book and the practical issues involved in the development of an Internet e-commerce application. The hands-on exercises allow you to detect, identify, and correct critical errors on your own, before reviewing the solutions provided in the book.

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

* 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 click below:

* 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 click below:

* 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 click below:

*** M&T News ***********************************************************

* Lauch of the Methods & Tools discussion board

A discussion board has been set-up on the Methods and Tools website. Its goal is to improve the communication between readers and allow them to give feedback to the editor and the authors. It will also serve as an announcement board for the software development tools vendors community, a type of information that was not finding its place in the PDF issues or Facts newsletters. I hope that you will it useful. As always, your suggestions to improve this discussion board are welcome. 

Forum URL:

You will have to register to post on the forums. The registration to the forum is independent of your subscription to Methods & Tools.


* Coming UP

In the Spring 2004 issues (published at the end of March), we will have articles on Precise Use Cases and Identifying your Organizations Best Practices. Stay tuned!

November 2022
October 2022
September 2022
August 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
June 2019
May 2019
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

Methods & Tools
is supported by

Software Testing

The Scrum Expert