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 2002
*** Companies ***********************************************************
* European IT Services Consolidation
The end of 2001 has seen some consolidation moves in the European IT services industry. EDS has reached an agreement with Alcatel, the French telecommunication equipment producer, to take over its IT services subsidiary, Answare SA. EDS has also been involved in the bankruptcy of Swissair, the Switzerland national airline. It has bought Atraxis, Swissair's IT subsidiary, which is also providing reservation systems to other airlines, like South African Airlines. In both cases, EDS is getting a "sure" deal because both target have customers that are fairly "locked". Revenues of EDS rose 16 percent in the third quarter of 2001.
At the same time, computer manufacturer Groupe Bull of France (do you remember the - not so long ago - time when every European Nation has its own computer company with its own operating system...) has agreed to sell Integris, its integration and consulting unit, to French software house Steria.
These moves are examples of the "bigger is better" mentality that is currently prevailing in the IT services and consulting industry. Size should allow to decrease the sales and administrative overhead, gain credibility and shuffle resources more flawlessly between projects. But is big really beautiful?
*** Numbers *************************************************************
* Small is Beautiful
A study of response times done by Media Metrix shows that sites with the higher number of unique visitors/month have the fastest response time for their home page. This due to the fact that they try to minimize the size of this page.
Web site | Size (in KB) | Unique visitors |
AOL | 36.7 | 69'374 |
Microsoft | 46.8 | 59'852 |
Yahoo! | 27.1 | 57'522 |
Lycos | 15.5 | 32'384 |
Excite | 47.5 | 30'535 |
About | 55.3 | 23'588 |
CNET Networks | 77.4 | 18'435 |
Amazon | 86.3 | 18'046 |
Source: "Understanding and Reducing Web Delays", M. Zari, H. Saiedian, M. Naeem, Computer, December 2001
This could serve as a reminder for those who want to abuse of big graphics or flash animations on home pages. It is to be linked with the fact that the average "patience time" of the Web surfer is only 7 seconds... and then he clicks away!
*** In Other's Words ****************************************************
* Know Your Enemy
"Every body in the methodology business agrees the big problem is not Methodology A versus Methodology B, but rather any methodology versus none".
Barry Boehm cited in "New Center Will Help Software Development Grow Up", Greg Groth, IEEE Software, May/June 2001
Isn't "Code As Fast As You Can" considered a methodology?
* Nirvana
"Software engineers have been trying for years to manage requirements better. The reasons are simple. A slight change to requirements can profoundly affect cost and schedule because their definition underlies all design and implementation. We have been taught to spell out the requirements at the beginning of a project and not to change them. Experience has shown that these lessons are impractical and impossible to achieve.
For years, I have watched software engineers strive to create requirements specifications. They have tried to scope the functional, performance and interface requirements using a variety of specifications techniques and notations. Often, they developed specifications long before starting their projects because that's what the experts taught. The experts advised us to define what we wanted before we figured out how to develop our software. Involving the user or customer was considered a key to success. Firming up the requirements before starting was the industry best practice because specifications formed the foundation of our design and coding activities. We were taught to negotiate each modification with the user because of the cost and schedule impacts. After all, nobody in his or her right mind would expect something for nothing.
The only thing wrong with these techniques is that they don't work in today's environment. As most start-ups have figured out, rapid prototyping and applications methods have supplanted the waterfall life-cycle model on which these techniques were based. Architecture-driven methods have eliminated the need for these document-driven development approaches. What's most important is that we finally have the guts to admit to ourselves that we don't know precisely what the system should do when we start the project. We have discovered that requirements development is a learning than gathering process. We know we need to work with users or customers to understand their expectations and win conditions for success. [...]
Software engineers are not masters of their own destiny. For instance, they are not in charge of requirements and never have been. You are probably asking, "if you can't control the requirements, how can you manage them?" and "who specifies requirements?" More often than not, a team comprising marketing and system-engineering people defines the features and functions that form the product's crux.[...]
As the development progresses and people and situations change, so do requirements. That's natural. As the spiral model unfolds, the customer and the requirements definition team learn more about what the product should do through continuous exploration and refinement. It is therefore naive to believe that we can specify in detail what the customer wants at the beginning of the job. The best that we can do is control the continuing definition of the requirements as they change throughout the life cycle. Yes, we can and should manage a requirements baseline and track its changes. We can also trace requirements to their source and show their evolution. But managing traceability is quite different from managing requirements changes. We can only anticipate and respond to requests for change. We cannot dictate either the frequency or the desirability of changes.[...]"
Source "Requirements Management: The Search for Nirvana", Donald Reifer, IEEE Software, May/June 2000
The presentation of the changeable nature of requirements is right and the abandon of written requirements is an appealing idea. You should however not forgot that the creation of requirements have other benefits: they are used by developers to learn the user business domain and vocabulary, they are the basis of software project estimation, they allow to bring perspectives that are not evident at the code level (an object life-cycle for instance), they are a definition of what the system should do and how to test it, they are the base of customer-supplier contracts for software development, etc. If you choose alternate techniques, like rapid prototyping for instance, you should be able to find other ways to fill these functions, depending on the short and long term needs and perspectives of your application.
*** Conferences *********************************************************
Software Test Automation Conference -- March 25-28 in
San Jose
http://www.sqe.com/testautomation/mt02
SQE's Software Test
Automation Conference shows you how to add more automation to your
testing and ensure you have a better product going out the door -- every
time.
-------------------------------------------------------------------------
5th Software & Internet Quality Week Europe
(QWE2002) - Internet NOW!
11-15 March 2002, The
Sheraton, Brussels, Belgium - www.qualityweek.com
Check out the entire program with detailed descriptions of multiple
tracks, abstracts and authors on the web site:
www.soft.com/QualWeek/QWE2002/program.phtml
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |