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:
http://www.eclipse.org
http://www.netbeans.org
*** 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, www.sdtimes.com
----------------------------------------------------------------------
* 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 http://www.methodsandtools.com/poll/poll.php 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 amazon.com click below:
http://www.amazon.com/exec/obidos/ASIN/1590590961/methotools-20
* 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 amazon.com click below:
http://www.amazon.com/exec/obidos/ASIN/: 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 amazon.com click below:
http://www.amazon.com/exec/obidos/ASIN/0201730391/methotools-20
* 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
*** 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: http://www.methodsandtools.com/forum/index.html
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!
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |