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 2003
*** Companies **********************************************************
Even Big Fishes Are Eaten
At the beginning of December, IBM announced that it will buy Rational Software for 2.1 billion dollars. Rational will add to IBM roughly $700 million additional yearly sales and most of its 3400 employees in its software group. Rational will be kept as a brand for IBM development tools. The revenues for this division are $5 billion. Rational co-founder and CEO Mike Devlin will serve as general manager of the division.
This acquisition is positive for IBM. Rational is the "biggest" brand in the software development space. It will add upscale development tools to a product mix that was more code-oriented with products like Websphere or DB2 (this division is already itself digesting Informix). Rational will also give IBM a solution for the Microsoft .NET platform. For Rational it is perhaps a solution to its dependence on (temporary?) alliances with code development companies like Borland, Microsoft or Oracle. Recently for instance, Borland made the acquisition of Togethersoft, integrating therefore a modelling tool which is a competitor of Rational Rose. At the beginning of December, Rational cancelled its agreement with Borland to bundle Rose with Jbuilder.
As far as price is concerned, the purchase seems to be an indicator of the poor state of software development market. The $2.1 billion price paid by IBM values the Rational share at $10.5, far from the $69 price it has reached in September 2000, but around twice the current share price before the deal was announced. To put a comparison, Borland valued Togethersoft also three times its revenues and IBM acquired PWC Consulting for a price corresponding to 70% of its revenues. Even if it is more difficult to achieve a high growth rate with a $700 million company, this acquisition could also mean that Rational decision makers have a minimal faith in a improvement of the software development tool market and that their shares could regain soon their past glory.
According to some analysts, this acquisition is good news for "independent" player like Borland or other. The idea is that some companies will be reluctant to have an all-IBM solution (or even part of it...). I am not so sure. To gain credibility with major accounts, smaller companies often need to be associated with more established players that have holes in their product offering but the sales force to open doors and to support contact with important customers. Perhaps relatively large companies like Borland or CA can do well in a stand-alone mode, but smaller companies are left with fewer bigger player (anything behind Sun?) that can be their ally without fearing of being a future competitor.
*** In Other's Words ***************************************************
* Software Management Principles
Top 10 Principles of Conventional Software Management:
- Freeze requirements before design.
- Forbid coding before detailed design review.
- Use a higher-order programming language.
- Complete unit testing before integration.
- Maintain detailed traceability among all artifacts.
- Thoroughly document each stage of the design.
- Assess quality with an independent team.
- Inspect everything.
- Plan everything early with high fidelity.
- Rigorously control source-code baselines.
Top 10 Principles of Modern Software Management:
- Base the process on an architecture-first approach.
- Establish an iterative life-cycle process that confronts risk early.
- Transition design methods to emphasize component-based development.
- Establish a change-management environment.
- Enhance change freedom through tools that support round-trip engineering.
- Capture design artifacts in rigorous, model-based notation.
- Instrument the process for objective quality control and progress assessment.
- Use a demonstration-based approach to assess intermediate artifacts.
- Plan intermediate releases in groups of usage scenarios with evolving levels of detail.
- Establish an economically-scalable, configurable process.
Principles that Didn't Make the Cut
A comparison of my top 10 principles with other lists, such as the Software Project Management Network's Best Practice Initiative or the SEI Capability Maturity Model's key process areas, reveals several notable omissions.
- Requirements-first emphasis. The most obvious difference is my apparent underemphasis on requirements. Requirements are a means, not an end. Conventional wisdom has overprescribed "better requirements" as the cure for recurring project woes. Requirements, designs and plans should evolve together.
- Detailed planning and "inch-stones". Overplanning, another misapplied practice, is different from evolutionary planning. Early false precision is a recurring source of downstream scrap and rework.
- Inspections. Inspections are overhyped and overused. While properly focused inspections help to resolve known issues, inspections too often are used to identify issues and provide quality coverage. Human inspections are inefficient, labor-intensive, and expensive. In my experience, inspections can uncover many cosmetic errors, but they rarely uncover architecturally-significant defects.
- Separate testing. Testing is not covered by a separate principle; it is covered by all of them. A modern process integrates testing activities throughout the life cycle with homogeneous methods, tools and notations. The integration of interfaces, behaviors and structures should be emphasized before concentrating on completeness testing and requirements compliance.
- Separate quality assurance. The much-touted concept of a separate quality-asurance reporting chain has resulted in projects that isolate "quality police". A better approach is to work quality assessment into every activity through the checks and balances of organizational teams focused on architecture, components, and usability. Quality is everyone's job, not one team's job.
- Requirements traceability to design. Demanding rigorous problem-to-solution traceability is frequently counterproductive, forcing the design to be structured in the same manner as the requirements. Good component-based architectures have chaotic traceability to their requirements. Tight problem-to-solution traceability might have been productive when 100% custom software was the norm – those days are gone.
Source: Walker Royce, "Software Management Renaissance", IEEE Software, July/August 2000
Interesting basic thinkings on the evolution of software management. Perhaps the most important is why some old principles are not in the current list...
*** Web Siteseeing ****************************************************
The World Wide Web Consortium - http://www.w3.org
The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) for the Web. W3C is a forum for information, commerce, communication, and collective understanding. You will find information on some standards (HTML, CSS, XML, SOAP...) of Web-based applications and you will be able to participate to their evolution. There are a large number of sections in the site. You will find below a small selection of links:
HTML. This is W3C's home page for the HTML Activity. Here you will find pointers to our specifications for HTML/XHTML, guidelines on how to use HTML/XHTML to the best effect, and pointers to related work at W3C.
http://www.w3.org/MarkUp
W3C MarkUp Validation Service is a free service that checks documents like HTML and XHTML for conformance to W3C Recommendations and other standards.
http://validator.w3.org
Clean up your Web pages with HTML TIDY. The software is now developed on the open source site Sourceforge.net, but there is useful information on the w3.org pages.
http://www.w3.org/People/Raggett/tidy
http://tidy.sourceforge.net
Web Style & Cascading Style Sheets (CSS)
http://www.w3.org/Style/CSS
CSS validator
http://jigsaw.w3.org/css-validator
The Extensible Stylesheet Language (XSL)
http://www.w3.org/Style/XSL
Extensible Markup Language (XML)
http://www.w3.org/XML
How to add style to XML
http://www.w3.org/Style/styling-XML
Web Services. Publicly developed, SOAP Version 1.2 is a lightweight protocol for exchanging structured information in a decentralized, distributed environment
http://www.w3.org/2002/ws
*** Conferences *******************************************************
Bay Area Hosts Software Test Automation Event -- March 10-13
Join us in San Francisco for the one conference that can help you effectively deal with your software test automation issues. Focused only on test automation, this combined education and EXPO event delivers solutions via a select group of industry experts, plus a technical staff of leading tools and service providers. You can even visit the event Web site and sign up for a FREE one-day EXPO pass!
Visit the Software Test Automation Conference & EXPO online at: http://www.sqe.com/testautomation
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |