Saturday, March 02, 2002

Components. If you're involved in component-based software development, Robert Fichman's paper titled Activity Based Management of Component-based Software Development is a well thought-out approach that provides a lot of insight. You can also download the paper in PDF format for off-line reading. You'll also want the accompanying tables if you download the base document.

Software Metrics. Robert Fetcke has a comprehensive list of software metrics sites that you'll want to bookmark. On the topic of metrics, version 4.1 of COSMOS, a software cost estimating tool from Oak Ridge ETSU Design Studio Group is a free tool that is both sophisticated and a step forward for project managers and estimators. I've been using this tool since it was first released in the mid-90s as SEAT.

Assurance. In my last entry in Postcards from the Revolution I discussed security standards, with a focus on international standards. One such standard is Common Criteria, discussed in previous entries. The Common Criteria is a security standard for assurance, which fits within the theme of this weblog. One specific article that is interesting is Banking Industry View of Common Criteria. If you work with the banking industry and are involved in either security or SQA this article is essential reading.

Risk and quality go together. You risk much if you take shortcuts to quality. An MS Word document titled, Can Quality Management Systems Improve Your Software Development and Business Performance? explores one half of the risk-quality relationship. A whitepaper titled Software Risk Management explores the other half. Additional papers can be found on the NIST Software Quality Group page.

End Notes. On 11 June 2001 I wrote a book review of Configuration Management for Software by Stephen B. Compton, Guy R. Conner, Joan R. Callahan. The book was out-of-print when I wrote the review, but because Amazon sells used books I thought the effort to write the review was worthwhile. I've read numerous books on the subject and this was the best one among them. I was recently contacted by one of the authors, Joan R. Callahan, who mentioned that a revised edition was being considered. If you have ideas and opinions about SCM, or want to voice your support and encouragement, please send Ms. Callahan your comments. I, for one, would love to see the book back in print.

Friday, March 01, 2002

Am I Certifiable? Some would say yes before they hear the full question. In fact I am considering pursuing certification as an Oracle Certified Professional. My reasons are simple: (1) Oracle is an industrial strength database that is one of two choices for high-availability systems (the other is IBM's DB2), (2) back-end databases are the foundation of e-commerce, ERP, CRM and knowledge management, so being certified in Oracle will enable me to add value to any project to which I'm likely to be assigned, and (3) it is about the data - everything else is there to facilitate using it properly. If you read Mike's 28 February entry in Postcards from the Revolution you'll see what I mean.

Process and Structure. I've obviously been researching Oracle and found some interesting sites and documents that I want to share:

Risk & Opportunity. Much of Mike's latest writing here and in Postcards from the Revolution is about quality, project management and processes. Get into any of those topics and you'll find risk management at or near the core. A risk is an opportunity in disguise. The difference between a disaster and an opportunity is calculation - a calculated risk is one in which you know the probability of the risk and what it will cost if it does occur. Using Probability times cost results in an impact. A few papers on risk management that I particularly like are Risky business: what we have yet to learn about software risk management by Shari Lawrence Pfleeger, and A Survey Instrument for Quantifying Software Maintenance Project Risk by George E. Stark and Paul Oman. These papers look at vastly different aspects: one is an essay about how the software engineering community is using flawed techniques to assess and manage development project risk. The other addresses the opposite end of the life cycle by examining risks inherent in software maintenance.

QA professionals who are reading this will want the collection of slides (in PDF format) from a presentation titled Risk-Based Object Oriented Testing. The 20 slides in this document cover risk management in general, and testing OO systems using a risk-based approach in particular.

Mike and I have both reviewed risk management books on Amazon that you should consider if risk management is a topic that interests you:

Process. I'd like to add a few documents to those that Mike provided in his earlier entries this week: Software Defect Reduction Top 10 List by Barry Boehm and Victor Basili shows the first places to look when you're seeking to reduce defects. This is an excellent article and a powerful counter-argument against those who don't believe in process.

Measurement-Based Guidance of Software Projects shares sophisticated software project management techniques that are centered on project planning. With the high failure rate of IT projects, we as a profession need to start embracing techniques that have been proven in other industries. This paper has information that will take us a step closer to that goal. Another article on advanced project management techniques is Statistical Process Control of Project Performance from the March 2002 issue of CrossTalk Magazine. If you're not reading CrossTalk and you're in the applications delivery domain, you should start reading it - you may be competing with someone who does read it for a job or contract, and guess who will probably win out.

TGIF!. The day is quickly melting away, so I'm going to do the same and wish you a wonderful weekend from Azusa, California.

Thursday, February 28, 2002

Reliability, Quality and Process. My entries here and in Postcards from the Revolution have a recurring theme: quality. Reliability is a function of quality, and process is the means of achieving quality. Moreover, quality is the main issue in my essay about the economic war in which we're engaged, whether or not we want to acknowledge that fact. However, I am not going to add to the essay in this entry; instead, I'm going to share documents about reliability, quality and process that anyone who is in our industry will find useful.

Reliability. No discussion of software quality would be complete without citing work by John Musa. He is considered to be the father of software reliability, and his influential (and now out-of-print) book, Software Reliability: Measurement, Prediction, Application, launched software reliability as a discipline. His most recent book, Software Reliability Engineered Testing, was published in 1998 and updates his original book with experience gained during the eleven years between the two books. My 11 May 2001 Amazon review of Software Reliability Engineered Testing gives a synopsis of the book, but you can learn more about the approach on Mr. Musa's SRET web page.

Victor Basili is another prominent figure in the software reliability community. His home page contains a list of publications to which he's contributed or authored, and conference proceedings at which he's presented.

If you're involved in software reliability you'll find the Tactical Software Reliability Guidebook to be an invaluable resource. Be aware that this 138-page PDF document is 11 MB and resides on a painfully slow server. If there is sufficient interest I'll place it on my server, which will support faster downloads.

Quality. This subject is vast and encompasses a wide range of subdisciplines. In keeping with my essay's theme I'm going to stick to a narrow view, starting with Cem Kaner's paper titled, Quality Cost Analysis: Benefits and Risks. Closely related to this is an interesting paper titled, A Quantitative Quality Index for Your Application Development Process. Don O'Neill has also contributed to the cost of quality body of knowledge, especially with his work with the National Software Quality Experiment. I also found his short paper on Software Inspections Return on Investment informative and a valuable source with which to make a business case for inspections and walkthroughs.

As luck would have it, the March 2002 issue of CrossTalk just arrived in my mailbox, and the entire issue is devoted to quality and metrics. The first article, Don Reifer's Let the Numbers Do the Talking is a treasure trove of data that addresses both quality and project management. Mr. Reifer is a favorite author whose published works include Software Management (see my 22 September review on Amazon), Practical Software Reuse (I also reviewed this on 22 September), and Making the Software Business Case: Improvement by the Numbers, which Linda reviewed on 22 September.

The article titled How CMM Impacts Quality, Productivity, Rework and the Bottom Line by Michael Diaz and Jeff King nicely ties together the relationship between process and quality.

Process. Believe it or not, but there are those in IT who are anti-process. I call them cowboys and cowgirls when I'm being politically correct. In private I usually refer to them as misguided (when I'm feeling charitable), or clueless (when I'm feeling less charitable). Certainly the foregoing article on how CMM impacts quality, productivity, rework and the bottom line makes a strong case for a process. However, processes do not spring up and take hold by magic or wishful thought. Suzanne Garcia's article titled, Are You Prepared for CMMI? is a short, well-written piece about adopting CMMI that can apply to any process. A good starting point for software engineering processes is SEI's page describing their SEI Software Engineering Process Management Programs. If you're seeking guidance on implementing the CMM, or any initiative of similar complexity, I strongly recommend CMM Implementation Guide: Choreographing Software Process Improvement by Kim Caputo. My 3 July 2001 Amazon review sums up why I think the book is valuable.

An additional source of information is a page about process improvement frameworks, which introduces a quality improvement paradigm, and briefly describes three techniques: Goal/Question/Metric, Assess, Analyze, Metricate, Improve, and the personal software process (PSP). This page is complemented by another page on Software measurement, which is the foundation of any software quality process.

The connection between quality and costs is shown in the following documents:

All of these support the cost of quality (and non-quality) premise upon which my quality philosophy is built.

Parting Shot. A page from a University of Calgary software engineering course contains a few horror stories that stemmed from either lack of quality, process or both: Introduction to Software Engineering Process. It delights me to know that this is being taught in universities, and it reinforces my opinion that IT practitioners without degrees may be a part of our profession's reputation for failures and questionable value to the businesses that we're supposed to be supporting.

I'll be posting related material later today in Postcards from the Revolution. If you're not reading that weblog you're only getting half of the picture.

Wednesday, February 27, 2002

Knowledge Exchange, Knowledge Gained and Miscellaneous Gems.I've had an ongoing participation in a forum about my essay on the real war (see my entries from 21 February on). The essay has triggered comments and yielded insights from a number of people, and the resulting knowledge exchange, some in the form of debate, has proven valuable.

Exchange. Comments in the forum revealed the usual split between the process and anti-process camps, with both sides making compelling arguments to support their views. Most of the participants were articulate and persuasive, and I wish I had more time to spend on the forum, but I regretfully need to scale back my participation. Other commitments have a higher priority.

Knowledge Gained Among the points made during the discussion the following influenced me the most:

The notion that processes may be too heavy for many organizations, particularly the CMM. Indeed, they can be if improperly developed and implemented. I am not sure that most people understand the CMM, which accounts for the disconnect. However, understanding the CMM doesn't necessarily confer the wisdom to tailor it correctly to meet organizational goals.

The CMM is a maturity model. It was developed after extensive studies of successful organizations were performed with the goal of finding out what made them successful. During the course of the studies relationships between organizational maturity and process areas began to emerge. This led to a correlation between key process areas and an ability to predict how effective an organization would be using those processes to produce quality software in a cost-efficient manner. As the model was refined five organizational types emerged:

  1. Initial (ad hoc or chaotic)
  2. Repeatable
  3. Defined
  4. Managed
  5. Optimizing
Each level has a set of minimum processes that must be employed. The increase in capability maturity is a function of the number of defined processes that are used by an organization. The CMM does not, however, define any of the key processes in specific terms. Each has certain characteristics, but the details are left to the organization itself.

When an organization has been assessed to be at a particular level of capability maturity it means that all of the processes prescribed for that level have been effectively implemented, that there is evidence of commitment to perform in accordance with the processes, as well as evidence that the processes are employed in the routine operations of the organization.

It's the job of the assessor(s) to assure that the forgoing conditions are met. Therefore, while they pass judgement on whether or not required processes are in place and are effectively employed, they do not judge the efficiency of the processes. It's not inconceivable for a CMM Level 3 or above organization to use processes that are inefficiently implemented and actually hamper the organization in some way(s).

I have two documents that discuss how to implement the CMM for small organizations and projects:

  1. Capability Maturity Model for Extra Small Organizations by Terttu Orci (PDF format, 48 pages).
  2. Using the Software CMM in Small Projects and Small Organizations by Mark C. Paulk (PowerPoint presentation in PDF format, 33 slides). More wisdom from Mr. Paulk comes in the form of another presentation titled Using the Software CMM with Good Judgement. Key points are common sense, small projects and agile methodologies.
However, the CMM isn't the only approach. In future entries I'll discuss SPICE (Software Process Improvement Capability dEtermination) and Bootstrap. If you want more information on these before I get around to discussing them the best source is Tantra's Informational Hotlist, which is updated quarterly.

Gain. I've been focusing on project management, security, best practices and process improvement in recent Postcards from the Revolution entries. There is some overlap and crossover between this weblog and Postcards from the Revolution. My latest topics were best practices, which fit within the real war thesis in that I feel that there is a dearth of them practiced.

One way to develop and document practices that work is to use patterns (discussed in numerous entries here and in Postcards from the Revolution). A book titled Framework Process Patterns: Lessons Learned Developing Application Frameworks is scheduled to released on 15 April, and from the table of contents I think this is going to be a valuable addition to the methods and frameworks body of knowledge. Until the book is available you may find Pattern Oriented Approach to Software Process Evolution to be an interesting prelude because it parallels some of the material in the book. This document is in PDF format and is a succinct five pages. Another document, in MS Word format and written by Suvajit Gupta is titled Software Development Patterns.

Gems. One of the gems on the web is Jack Harich's home page. Mr. Harich's collection of topics and papers is nothing short of amazing. Some examples include: Simple Unified Process, which is a sensible approach to implementing a scaled down version of the Rational Unified Process, and Optimizing Project Management, which is a collection of best practices and sage advice. Mr. Harich is also published in a number of magazines, and one of his articles in JavaWorld, The myth of code-centricity, shows that he's given software engineering processes and real-world applications of the processes a lot of thought.

Defining the Software Process is an online presentation that covers the basic processes that mature software engineering organizations employ. I also have a Zip archive containing four PowerPoint presentations on software project management that will complement my recent entries in Postcards from the Revolution and in earlier entries here.

End Notes. Reports of my death have been greatly exaggerated. If you've sent me e-mail during the past week and haven't received a response it's because I've been inundated. Tomorrow is e-mail catch up day. Please accept my apologies and bear with me.

I have one final document that I want to offer: Intrinsic Information Security, subtitled, Embedding security issues in the design process of Telematic Systems. This 352-page PDF document is valuable for a number of reasons, the foremost of which is the importance of basing an architecture on security goals. It also exposes best practices in architecture, software engineering and assurance.

Tuesday, February 26, 2002

Tidbits. I'm playing catch-up today, so this entry is going to contain an eclectic collection of news items.

Maneuvering. A 25 February article in ZDNet Tech Update titled, BEA touts 'Visual Basic for Java' is an interesting twist on Microsoft's own tactics. The article extends a 12 February ZDNET Tech Update titled, Microsoft's Java jitters.

Stumbled Over This. McGee's Musings is an interesting weblog I recently discovered. It's an eclectic collection of business, social and technology issues, and one that I've bookmarked. It's maintained by Jim McGee, who is a professor at the Kellogg School of Management, Northwestern University. Jim also maintains a companion weblog which contains references supporting his Tech-911 course.

Blame? Who, Me? eWeek has two thought-provoking articles:

  1. Security: Time to Take Names, Lay Blame by Jody C. Patilla (25 February 2002)
  2. Security Quandary: Who's Liable? By Dennis Fisher and Chris Gonsalves (25 February 2002)
In the "What Else is New?" department The Register's 22 February article reported Three new MS security holes - two nasty.

EU Muscle. The Register reported another indication of EU self-determination in the 21 February 2002 article titled, EU thumbs nose at US with software patent proposals. This one goes into the pile of citations for the part of my essay that asserts we are in an economic war. I'm sure the pile will grow.

Sad News. In my 19 February entry I reported that Process Dashboard v1.4 was available. I received an e-mail today with the following sad news:

Watts Humphrey, the creator of the Personal Software Process(SM), has requested that we not distribute the Process Dashboard until further notice.

Also, in accordance with Watts' direction, "anyone who has previously downloaded copies of the Dashboard is no longer authorized to use, copy, modify, distribute, or otherwise handle this material in any way."

Please direct questions to the development team.

I'm on the mailing list and will report any changes to the policy here.

End Note: The February 2002 issue of the Quality Techniques Newsletter is out. If you're a quality professional I strongly encourage you to get a free subscription. A highlight in the February issue is Testing Your Web Application: A Quick 10-Step Guide by Krishen Kota.

Essay Progress. In my 23 February entry I mentioned that my ongoing essay here was picked up as a topic in a discussion forum. A few members of that forum have made valid points that show where some of my assertions have flaws or need additional thought. For example, in my 22 February entry under Situational Analysis, list item 3 I discussed how the US steel, automobile and consumer electronics industries were world leaders when I was growing up. I later mentioned that US TV manufacturers, also world leaders at one time, are completely extinct. A reader identified as DJAgain posted an interesting and valid reason why the TV industry was a bad example:
During the Eisenhower administration, Japan was basically "given" the TV industry. The US Government lowered (manipulated) the import duty on electronics in exchange for Japan's approval to locate U.S. Bases in Japan. At the time, these bases were a strategic necessity because of the cold war with China. In addition to having 1950's -era cheap labor, the Japanese also manipulated their exported prices even lower, and made up the difference by charging their own citizens a 50-100% markup for the same TV.
He ended with a powerful observation: "American companies just couldn't compete because of our Government's manipulation of the law. Sound Familiar?"

A readner named Greg gave some well thought-out reasons why my analogy using the auto industry is a bad example. His comments have merit:

While one may argue that Japan or German cars are better quality than domestic they are certainly not much cheaper ( and many are in fact more expensive in comparable class); as for the production speed I assume it's about the same, isn't it? But even more important, these examples (cars, TV sets, steel ) are valid for mass production, "commodity" industries while most of the IT/software projects are "custom-made". I agree that in the IT areas suitable for mass production, e.g. building class libraries according to the detailed specs the competition may work better ( like building "Japan" TV sets in Malaysia according to the detailed blueprints).
I also gained insights from posts by David Cressey on Stages of International Competition and an individual named ILoveCoding, who has posted a number of well written responses. The following, titled Quality problems ... process and culture, is one of my favorites. ILoveCoding clearly has a quality-oriented background and in-depth knowledge and experience in project management and software engineering processes.

Expanding Energy. Linda and I have a symbiotic relationship. Her strengths compensate for my gaps, and my strengths do the same for her. Where I tend towards the abstract, Linda is grounded and pragmatic. We have a perfectly balanced, harmonious working relationship that complements our friendship. Kate Hartshorn has joined the mix and she's been actively collaborating with me on a number of ideas. Her fresh ideas and perspectives add much to TEAM Zarate-Tarrani, and her positive personality contributes to an interesting team dynamic. Kate has a BA from University of California, Irvine, in Social Ecology, and an extensive background in business and competitive intelligence. She is also one of the most efficient and effective researchers with whom I've had the pleasure of working.

End Note: Doug Kaye has consolidated his weblogs. His index page has the latest details, but the two weblogs that have emerged are Web Hosting Strategies and Web Services Strategies. These weblogs directly support Doug's outstanding book, Strategies for Web Hosting and Managed Services, which Linda and I recently reviewed on Amazon.

Monday, February 25, 2002

Recognition and Appreciation. On Sunday, 24 February Linda realized a life-long dream by strapping on a parachute and jumping out of an airplane. That act embodies Linda's essence: she lives her life to the fullest, and endeavors to experience everything worth experiencing. I greatly admire her and strive to follow her example.

A look behind the scenes: I write an entry here each day, and when she has time Linda also contributes. You see our names attached to the entries, but what you don't see is Kate Hartshorn's behind-the-scenes editorial magic. Linda and I will take responsibility for any errors, but I assure you that there would be many more if we didn't have Kate's editorial touch.

Sharing a Discovery. While reading Julian Bond's informative weblog I spotted a reference to The Chasm Group, which is a consulting practice focused on helping high technology companies achieve market leadership positions for their core products and services. Their newsletter is excellent, and their collection of articles is equally so. I also discovered an interesting site, SRI Consulting Business Intelligence.

Stepping Back. Today was so stunningly beautiful here in Tustin, California that I put the evolving essay on hold and enjoyed the sunshine and life itself. I do want to take a few minutes, though, to provide background material that will support my thesis that we're in the midst of a global war. In this war the battles are being fought on economic rather than military fronts. In military engagements one of the primary tactical objectives is to grab and hold real estate that positions you to control lines of communication. These lines include logistics, ability to freely maneuver, coordination and communications with supporting forces. The primary strategic objectives are always political, which are motivated by the self-interests of each side.

Scope. My focus is on the software industry, not global economics in general. However, an understanding of global economics is required. I'm tempted to include Adam Smith's The Wealth of Nations as background material. I'll spare you that for a few reasons: the book was written 226 years ago and, while it remains influential, it's archaic. It's a classic that many cite, but few have completely read. I do recomend two classics in their own right by Michael Porter: Competitive Strategy and Competitive Advantage. If you opt for one or the other, I recommend the older, but seminal, Competitive Strategy because it is germane to my thesis and will also give you insights into the business domain.

Less known, but [in my opinion] of equal importance to Porter's work is Adrian J. Slywotzky's Value Migration. If you want compelling reasons why you should read this book, read Linda Zarate's 15 August 2001 review on Amazon. Her review will also reveal this essay's genesis.

On Quality. If you've read more than a few entries here or in Postcards from the Revolution you'll quickly realize that both Linda and I rank quality as one of the most important aspects in the IT profession. I'm not going to recommend general quality recources, however, because there are a plethora of quality-related books and papers that are specific to IT. One book that I recently reviewed on Amazon that I recommend is Software Excellence: A Total Quality Management Guide. I've had this book since 1997, and wrote an Amazon review on 20 February 2002. One chapter that I particularly liked was Quality Function Deployment for Software. I've been a proponent of this technique for years. If you want an overview of QFD the PDF document titled, Using QFD For Assessing And Optimizing Software Architectures shows how this powerful technique can be effectively used in software architecture. If that paper piques your interest you might want to invest in a copy of Quality Function Deployment by Lou Cohen. I personally think this is the best book on the subject from among the half-dozen or so I own. Linda is partial to Step-by-Step QFD by John Terninko. See her 28 March 2001 Amazon review for details.

One final recommendation in this topic is Elements of Software Process Assessment and Improvement, a compilation of essays edited by Khaled El Emam. There are two reasons why I think this book is important:

  1. It covers all of the major quality models, including CMM, SPICE, Bootstrap and ISO 9000.
  2. It portrays international initiatives in software process improvement, particularly with respect to SPICE and Bootstrap, which are popular in Australia and Europe, respectively.
See my 20 September 2001 review for details.

Estimation and Measurement. You've probably come across the term 6-Sigma if you've been keeping up with quality literature in software engineering or even industrial manufacturing. To get you up-to-speed if you're new to the concepts or just haven't delved deeply into it, I have a Zip archive of 6-Sigma PowerPoint presentations that cover many facets of the subject.

Two articles that I recommend are Caspers Jones' Software Measurement Programs and Industry Leadership that also ties into my thesis with respect to the relationship between quality and competitive advantage, and Dr. Barry Boehm's article titled, Future Trends, Implications in Cost Estimation Models. These two articles are augmented by my most recent entry in Postcards from the Revolution, which addresses advanced project management techniques.

End Note: Entries here will be terse for the next few days while I clear items from my "to do" list. Stay tuned because I will be adding short pieces to the evolving essay that has consumed my attention for the past few days. Also be aware that what I write here is only half of the story - the other half is in Postcards from the Revolution.

Sunday, February 24, 2002

Some of my recent comments and assertions became a topic in a forum, in which one reader challenged some of my assertions about India's software quality posture. This is a fair challenge. In fact, my ending notes in the entry under the heading Checkpoints need cited references, which I am going to provide:
    • We're in a war, but it isn't a war against terrorism
    • Our opponents are not trying to conquer us, but they are driven by self-interests as are we
    • The market is global and we may get locked out of it to a large extent

    Sources: The seeds of the war is shown in a December 1999 article in Foreign Policy In Focus (Volume 4, Number 37), titled, U.S.-EU Trade Issues. This article gives a succinct history, hightlights problems with current (1999) US trade policy and makes recommendations to rectify them. It's provides a backdrop to the issues that have since emerged. Some of the material has been obviated by events since the article was written.

    A December 2001 piece in European Union shows the determination of the EU to protect its own interests. The article shows the chasm between the US and the EU with respect to claims of protectionism on both sides. This issue was foreseen in a 1998 article titled Schröder’s New Europe: When America Leads, Will the Allies Follow? (Source: American Enterprise Institute for Public Policy Research).

    The EU's unity and power is amply illustrated in recent challenges to the US. In November 2000 the Seattle Post-Intelligencer ran an article reporting that the EU confirms its threat of sanctions. The same source reported in January 2002 that the EU won that battle with the news that WTO rejects U.S. tax law. Another indication of the clout exercised by the EU is the 4 December 2001 Associated Press story published in the Everett, Washington Herald that reported Microsoft asks Europe to accept U.S. accord. Microsoft stonewalled the US Department of Justice; they are bowing to the EU.

    Another show of EU power and determination to protect self interests is the break with the US over Internet taxation. E-Commerce Tax, an information source focused on electronic commerce tax issues, reported on 16 December 2001 that EU Takes Another Step Toward Taxing Digital Products. They published a follow-up article on 13 January 2002 titled Taxation of International E-Commerce in 2001 (they also published an interesting 10 February 2002 article titled India To Go Its Own Way? that is an indication of other international initiatives and policy.) Confirmation of the EU tax initiative, breaking completely with US policy, was reported in The Register on 14 February in an article titled Europe to levy tax on US, non-EU web sales.

    So, yes, we are in a war and it's not against terrorism. And, yes, we can be locked out of a large part of the global economy by powers who are not squandering their resources on military adventures, but are not-so-quietly consolidating their power and competitive advantage.

  2. ASSERTION: A free market will choose quality and our software industry has still competition from India and the EU.

    Sources: Evidence of the quality gap between the US software industry and the rest of the world can be discerned from the Software Engineering Institute's (SEI) SEI Maturity Profile August 2001. The findings of this report show that at CMM Levels 3-5 US organizations lag behind offshore organizations. The preponderance of the offshore organizations are in India as shown in the SEI's Published Maturity Levels of organizations that have achieved CMM Level 2 and above.

    A specific validation of India's lead in software engineering excellence comes from CrossTalk Magazine, which is the US Department of Defense Journal of Software Engineering. The August 2001 issue contains an article titled State of Software Development in India that validates my assertion that India is taking the lead in software quality. This is also validated in Adam Smith and The Software Industry, which was published in the October 2001 issue of The Data Admistration Newsletter. In this article the author, Norris Goff, relates first-hand experience in using India software companies as a source of high quality development and ends the article with: No company with major software development expenses can be competitive today without operations in India or a comparable offshore location, and there are very few alternatives ..."

I will address the final assertaion that [o]ur [elected and appointed] government allowed a monopoly to become established ... that has stifled development of our software industry and potential innovations in a future entry.

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]