TEAM Zarate Tarrani Notes From the Field

More Books. I've discovered two excellent books, both of which I've recently reviewed on Amazon. As I wrote the reviews it occurred to me that the overall quality of IT-related books has dramatically improved over the past two years. My two favorite publishers are Prentice-Hall and Addison-Wesley. These two imprints are now a part of the Pearson Publishing Group.

Testing. The newest book on software testing, and one of the better ones I've read, is Rapid Testing. This book provides a testing process and associated techniques that adds the agility required to meet fast-paced business requirements without sacrificing the due diligence or controls necessary to manage risk.

There is nothing especially new about the processes or techniques that the author proposes and explains; however, the way the processes are designed recasts tried and true methods into a streamlined process. Indeed, if the rapid testing process is correctly implemented it's possible to reduce testing cycle time while improving quality. I like the way the author begins by clearly defining terms. I know from experience that "acceptance test" means one thing in one organization, and something quite different in another. What I especially like, though, is the clear process itself, which consists of four major elements, each of which is thoroughly addressed in the book:

1. People.
2. Integrated test process.
3. Static testing.
4. Dynamic testing.

Another key strength of this book is the way the traditional (and much maligned) waterfall model is transformed into a hybrid called a parallel waterfall. This hybrid model is the best of the waterfall and V model, and like the V model, it tightly integrates testing and development. The author's approach to activity-input-output in the discussion of life cycle models is close to the entry-task-validation-exit process model, and the structure that is presented allows you to develop a process chain that produces predictable and repeatable results. This approach is partially why the testing process can be rapid without compromising quality or ignoring risks.

In Part II the book provides tips and techniques. Again, there is nothing especially new, but all of the key techniques are covered, including requirements and analysis, test planning, executing and reporting. Black box testing is covered well, as are an array of dynamic testing techniques (equivalence partitioning, boundary value analysis, memory leak testing, use case testing and performance tests.) If you're in a Microsoft-centric environment you'll appreciate the material on memory leak testing, and if you are in a development environment that employs UML or the Rational Unified Process the techniques for use case testing will prove helpful.

Part III provides detailed examples that are based on material presented in Part II. Overall this book lives up to its title by providing a 'safe' and effective process for rapid testing.

Project Management. One of the most exciting finds is Quality Software Project Management. This is, without a doubt, the most comprehensive book available on software project management. I don't make this statement lightly - I have over two dozen books on the subject, and have reviewed a significant portion of them on this site. It isn't the fact that the book consists of 33 chapters and 7 appendices and consumes nearly 1700 pages that makes it comprehensive. What distinguishes this book from the rest are:

1. A process-oriented approach that is completely consistent with the PMI PMBOK, fully supports requirements for the higher levels of the capability maturity model, and can be adapted to virtually any life cycle model.
2. It completely covers the important elements of planning, scheduling and control, including work breakdown structure development, associating tasks and deliverables, estimating (the focus is on the constructive cost model), advanced scheduling techniques (including critical chain scheduling that has emerged from the theory of constraints body of knowledge), and earned value project management.
3. Ties software engineering, system engineering, reliability, SQA and software configuration management to the project process. Many books briefly address these, while this book addresses the requirements, issues and techniques head-on.
4. Business plan development, requirements analysis, project deliverables and other artifacts are thoroughly covered.
5. The web site that augments this book has errata, templates and checklists (in HTML format), links and other material that supports using the book as a course text.

   There are so many things I like about this book, but the size and depth of content makes it nearly overwhelming. My favorite chapters are 21-Metrics, 26-Continuous Improvement, 28-Post Performance Analysis and 32-Legal Issues. However, these reflect my personal interests. The book is, in my opinion, uniformly excellent. The only flaw I found was the scant attention given to releasing an application or system into production, and no mention of how to tie together issue management to the enhancement and maintenance cycle that initiates once an application is in production. However, to be fair, this book is focused on project management and not software engineering. An outstanding companion to this book would be Successful Software Development by Scott E. Donaldson, Stanley G. Siegel, which provides the same in-depth treatment of software engineering as this book does for project management. See Linda's 11 September 2001 and my 5 September 2001 reviews of this book for more details.
   

   # posted by Mike Tarrani @ 9:09:00 PM

Gordian Knot. In my last entry I discussed complexity and perception. To many these topics are akin to the Gordian Knot, which if you know how to untie will give you skills and knowledge that will serve you well. I'm going to recommend two books that will help you to untie that knot:

1. Turning Numbers Into Knowledge: Mastering the Art of Problem Solving. This book isn't as much about numbers as it is about how to think. In fact, numbers aren't introduced until chapter 27, which is exactly midway through the book. The author, Jonathan Koomey, skillfully leads you through the process of learning to think critically, probe, question and analyze. Along the way he helps you to develop a mindset and collection of tools and techniques, which prepare you for the second half of the book that does cover numbers and how to interpret them, transform them into knowledge, and use them to solve problems. This 221 page book is a masterpiece because it's clearly written, offers sage advice and contains easy to perform--yet powerful--exercises throughout. Unless you've mastered critical thinking and problem solving you'll ignore this book at your peril.
2. Systems Thinking: Managing Chaos and Complexity (subtitled, A Platform for Designing Business Architecture) is to understanding complexity and perception that Turning Numbers Into Knowledge is to critical thinking skills. Like that book, this one has more to do with techniques and concepts than with what the title implies. To be sure, it does delve into designing business architectures, but the focus is on sorting through complexities and perceiving reality without filters. I'm going to share two examples that underscore this book's approach, and why I think it's one of the more important books one can read:
   • Counter-intuitiveness in social dynamics is illustrated with a cause and effect diagram that clearly shows counterintuitive behavior in a welfare system. The diagram shows how a program designed to reduce the number of poor families can actually cause the opposite effect.
   • A side story about a birth control project in India illustrates perceptual differences between and among cultures and deeply influenced my own perceptual awareness. The synopsis of this story is the foundation team who was trying to teach birth control gave an incentive in the form of a free transistor radio to anyone who attended their educational lectures. Despite their best efforts the birth rate remained at a steady average of 4.6 per family. This unchanging fact was a source of great dismay and perplexity to the team of Americans who were about to deem the project a failure. Fortunately they dug deeper into the causes and discovered that in India there are no retirement benefits, social security or unemployment benefits. The retirement system is based on three sons. It takes an average of 4.6 births to produce three sons, so the mystery was solved. This short story was used to reinforce a triad of factors that support decision making: cultural, emotional and rational. We tend to examine the rational, which represents only one third of what needs to be considered. The rest of this book contains the same deep insights throughout and gives you the tools and approach to untie that Gordian Knot.

If this topic interests you please see my entry today in Postcards from the Revolution, which uncovers some of the roots of contemporary knowledge management and collaborative computing.

I recently posted a review of Information Systems Success Measurement on Amazon. This book reflects best practices in a narrow discipline, and is important to anyone who is concerned with delivering (or proving) value using information technology. My review:

The nine chapters in this book are essays that are written by experts in their fields of expertise, with contributions by Garrity and Sanders who are credited on the cover.

Each of the chapters can stand alone, although they are presented in a sequence that build upon the preceding one. Each chapter ends with endnotes and references. Chapter 1 introduces information systems success measurement as a discipline. It does so in clear terms and is consistent with each of the subsequent chapters. Chapter 2, Dimensions of IS Success, is especially strong in that it introduces models, including DeLone and MacLean's model for IS success, and variations that show different viewpoints. It decomposes the dimensions into domains, provides questionnaires, and ends with an appendix that gives example ratings and measurements. This chapter shows how to quantify factors and portray success in hard numbers.

Chapter 3 extends the previous one by providing a 3-D model approach to measurement. Because I work in multi-cultural and multi-national environments I especially liked Chapter 4's focus on cross-cultural environments. In addition, the legal aspects of measurement that is Chapter 5's topic is essential reading. Regardless of your specific interests do take the time to read this short chapter because it applies to anyone in IS/IT. One glaring omission here is UCITA (Uniform Computer Information Transaction Act), which is an optional modification, on a state-by-state basis, to the Uniform Commercial Code (which is covered).

The remaining chapters address (Ch 6) Comprehensive Model for Assessing Quality and Productivity, (Ch 7) Development of Process and Outcome User Satisfaction, (Ch 8) Interpretive Approach to IS Success Measurement, and (Ch 9) Five Secrets to Systems Success. Each contained one or more interesting concepts and/or sparked ideas. Because much of my work as an IT consultant involves process improvement strategies and service level management I found this book to be an invaluable source of information. Each of the chapters contains valuable information, insights and ideas that will be useful to anyone in IT management or service delivery roles.

There are two documents that will interest anyone who is among this book's primary audience:

1. IT Efficiency and Business Value, which is a brief, nine-page overview.
2. Principles of Effective IT Management, that is more of a book. Its 186 pages, in presentation format, cover all of the key topics and is one of the best documents on the big picture available for free.

End Notes. I hope to find the time to continue my process discussion during the weekend. I'm sure that Kate or Linda (or both) will also contribute items of interest over the weekend.

My most recent entry in Postcards from the Revolution addresses the business requirements layer in the Tarrani-Zarate Model, and this material is directly related to IT critical success factors and value. Next up in that discussion is the link between business requirements and service level objectives.

My newest review just posted on Amazon. The book is Practical Software Measurement. What I couldn't say in the review, because Amazon doesn't allow URLs to be included in reviews, is you can download two chapters of the book directly from the PSM website:

1. Chapter 1, Measurement Key Concepts and Practices
2. Chapter 2, Measurement Information Model

More importantly, you can also download the official guidebook, an application called PSM Insight, and related whitepapers and documents. All are free, but you do have to fill in a simple registration form.

Things aren't as they always seem. Competitive intelligence specialists, knowledge management analysts and software engineers share one core skill: information gathering and analysis. It matters little whether you're seeking information about competitors or trying to nail down requirements, the tough part is recognizing what you see for what it is in reality.

The potential for misinterpreting an observation, statement of fact or a more subtle indicator is great. We're human and subject to mental filters that cloud or color our perceptions.

MIT's Perceptual Science Group has some interesting lessons in perception. I was fascinated (and amazed) by the simple, effective demonstrations of lightness perception and lightness illusions. While this doesn't appear to have much to do with information gathering it, in fact, has everything to do with it because it goes to the essence of cognition. We are knowledge workers, and cognition governs how well or poorly we perform any task that calls for analysis or reasoning.

Another resource that provides background material that connects perception with systems under observation, especially complex systems, is New England's Complex Science Institute's page on Visualizing Complex Systems Science.

Granted, this is not your normal fare for IT professionals; however, it does give insights about how we think and provides guidance on how to sort through complex problems. One final site that I think will interest anyone who wants to dig deep into cognition and perception is The Complexity & Artificial Life Research Concept for Self-Organizing Systems. This site isn't about the cutting edge of science and cybernetics - it covers arts and sciences. The page that interested me the most is about Value Metascience and Synergistic Choice. In plain terms the subject is about how to apply complexity thinking to the world around us.

Before you write this off as impractical theory that doesn't apply to what you do, remember this wonderful quote from Hamlet:

There are more things in heaven and earth than are dreamt of in your philosophy.

I think what the Bard was trying to convey is to not dismiss something out of hand because it seems to be outside of what you consider to be your frame of reference. The corollary is a quote from George Orwell's 1984:

I enjoy talking to you. Your mind appeals to me. It resembles my own mind, except you happen to be insane.

You decide.

Process - Part 2. I am picking up where I left off in my 11 March entry. In that entry I discussed the basics of processes and introduced the ETVX model. Today I am going to provide a real life process as an example for how ETVX can be applied to processes.

Example. Change control is a key IT operations management process that is governed by policy (more about policies tomorrow), and is accomplished through a series of tasks. Refer to the graphical depiction of the process as you read through it.

Entry Criteria. The change control process is initiated when there is a requirement to make a change. Change is defined as any of the following:

1. New system - application, operating system, database, hardware platform or infrastructure.
2. Major upgrade to an existing system - version release, new or upgraded components and/or subsystems (hardware or software), database schema reorganization, etc.
3. Minor upgrades to an existing system - patches, modifications to existing scripts or additional scripts (batch, shell, SQL, etc.), minor database schema reorganization (dropping columns, adding or modifying constraints, triggers and stored procedures, etc.) and infrastructure changes that are transparent to end users (i.e., upgrading IOS in a Cisco router, etc.).
4. Changes to service level objectives - permanent maintenance window changes, changes to problem management response times, mean-time-to-repair metrics, availability commitments, etc.
5. Maintenance to any system that has dependencies with the system being managed - in this special case the subject matter experts (SMEs) will open a change request to document the maintenance being performed on the inter-dependent system even though the SME has no direct control over, or responsibility for, the system. For example, if a particular application exchanges data with an application that is managed and supported by different SMEs, and is owned by a different application owner a dependency exists. The SME for the external application are responsible for initiating change control. However, since the change will affect the second application, that application's SME will open a change request as well. This provision will ensure that the scope of the required impact analysis will extend to all systems that are affected by the change. It will also ensure that each SME remain cognizant of any change or maintenance activity that affects his or her system.

The following are the minimum entry criteria that must be met before the process can move to the task stage:

1. Release notes, build analyses, installation manuals and any other documentation that is needed to correctly test and install the product (hardware or software).
2. Test results from QA (product test/UAT and/or pre-production/staging).
3. Operational requirements, such as special training, maintenance window considerations, help desk entry criteria, spare parts, etc.

Tasks.

1. Perform an impact analysis. Deliverable: completed impact analysis.
2. Develop planning package. Deliverable: description of change and why change is being made (including benefits and how the change will create value for the users), how the change will affect users during the implementation (scheduled start and end time, impact on maintenance window and service level objectives) implementation plan, roll-back plan, roles and responsibilities, notifications, quality assurance plan.
3. Provide operational requirements, implementation plan and change request to application owner and SME for review and approval.
4. Application owner approve change.
5. Technical owner approve change.
6. Submit change control package to change control coordinator.
7. Change Control Board reviews and approves the change request.
8. Change is implemented in accordance with implementation plan.
9. Change action is closed out as complete.

Validation. The following are checkpoints in the change control process:

1. All entry criteria will be checked for accuracy and completeness by the SME(s).
2. Application owner will review and approve the change request before proceeding.
SME's supervisor will review and approve the change request before proceeding.
3. The change control coordinator will review the implementation plan and change request for accuracy and completeness before including the change as an agenda item at the next scheduled change control board.
4. The change will successfully pass all post implementation validation test checkpoints before the change is released into production, else the change will be rolled-back.
5. In the event of a roll-back there will be a root cause analysis performed and responsibility for eliminating the root cause and, when applicable, developing a process improvement plan will be assigned to individual(s) by cognizant authority. The change request will also be cancelled and resubmitted after the root cause has been determined and eliminated.

Exit Criteria.

1. The change is successfully released into the production environment or cancelled and resubmitted depending on validation checkpoints above.
2. After a change is successfully released into the production environment the change control coordinator will close out the change request as completed.

Policies. It may appear that policies are mixed with this process, but they aren't. Tomorrow I am going to provide the policies that govern the process just described, then discuss the relationship between policies and processes.

Great News. Two items that made my day:

1. My 26 February entry announced the sad news that Process Dashboard was withdrawn. This open source application was designed as a Personal Software Process support tool. I am happy to announce that Process Dashboard is once again available.
2. Doug Kaye has launched a newsletter titled IT Strategy, which will come out weekly and cover news items about web hosting services and managed services, and web services. If these topics interest you (and they should) you can sign up for a free e-mail subscription.
Spin Control Out of Control. Today was intense and I'm getting caught up. Going through a backlog of unread e-mail I came across two message that, combined, made me chuckle. The first is from an old friend who now works for Microsoft. I'm on his distribution list and I read anything he sends. Here is an excerpt from the announcement that went out to the list:

Internet security is a worldwide issue that affects not just Microsoft's customers, but also anyone connected to the Internet- no one is immune to the problem.

Microsoft has taken a proactive approach to this problem by introducing the Microsoft Strategic Technology Protection Program (STPP). This two-phase program represents an unprecedented mobilization of Microsoft's people and resources to integrate product, services and support. In January, Microsoft Consulting Services presented an initial seminar that introduced the components of the STPP program, which includes" Get Secure" and "Stay Secure."

It sounded sincere enough. I paid a brief visit to Microsoft's security page, noted the proclamations, then mentally filed it away and planned to follow up at a later time.

Ironically, the next message was from a service to which I subscribe: e-Week. Here's the stories for today:

• IE, Apache Clash on Web Standard, ...The incompatibility lies in how Microsoft has implemented digest access authentication, a World Wide Web Consortium standard (RFC 2617) that specifies how users can securely log in to Web servers. Digest authentication is widely acknowledged to be the best available Internet standard for this purpose.
  The upshot is that IE cannot be used as a Web client for any Apache-based Web application that uses digest authentication. In addition, every non-IE browser we tested couldn't be used as a client for any Internet Information Services-based Web application that uses digest authentication.
• Security Flaws Found in IE 6.0 followed by Microsoft Patch Repairs 6 IE Flaws
Microsoft seems to be doing a lot of spinning and not much else.

On the other hand, e-Week also discussed the opportunities that more mature and proven technologies have, including an article titled Java: Potent Security that discusses the strengths of Java from a security viewpoint compared to Microsoft's newer .NET initiative. Another article from the same publication, Apache Avoids Most Security Woes, indicates that Apache is vastly superior from a security perspective than IIS.

Back in the Fast Lane. I'm caught up and will resume my entries here and in Postcards from the Revolution starting tomorrow.


# posted by Mike Tarrani @ 11:02:00 PM

Threats from the Web. In my 15 March entry I discussed the basics of competitive intelligence and sources of information. I've gathered some examples of threats (or opportunities, depending on where you're sitting) that underscore my discussion.

Be afraid ... be really afraid! Web job listings are one surprising source of information. As innocuous as job listings may seem, the paper titled Competitive Intelligence and National Security Threats from Web Job Listings shows that useful intelligence can be gleaned from publicly available sources. If this paper doesn't provoke reflective thought and a bit of paranoia you may be living in a different reality. Remember, when everything is uneventful the optimist will say, "we're safe" and the pessimist will claim that "we're due." I tend towards the pessimistic view when it comes to intelligence.

If the preceding paper didn't get your attention perhaps Civil Liability for Computer Security Professionals will give you pause. Although this paper is not specifically about competitive intelligence, it does show the potential risks a company faces if information that is made available isn't carefully reviewed by competent legal counsel. This document isn't for security professionals only. I think the proper audience should include marketing, content developers and corporate communications/public relations.

Other Matters. If you carefully read the US Government's advice contained in a document titled Intellectual Property: Navigating Commercial Waters you'll discover exposures to which your company may be subjected. This document is not ostensibly about competitive intelligence, but much of it is useful to those who gather or protect information that is considered to be competitive intelligence.

I still have loose ends on my personal web page, but will be rectifying them in the next few days. Mike is in the process of adding sample deliverables to our TEAM Zarate-Tarrani page, but this will be an ongoing process.

Linda left me an opening in her recent entry in Postcards from the Revolution to provide additional content about knowledge management. If you check my latest entry there you'll find five useful documents on the topic. Best wishes from Irvine, California.

Up for Air. I've been buried in projects, but feel guilty about not doing my part while Linda and Kate have been taking the time to write well thought out entries about important topics. Both have provided information and documents that are valuable and their writing is remarkable. If you haven't also been reading Postcards from the Revolution you're missing some excellent material on knowledge management and service delivery.

I am going to provide a few testing and reliability documents I've recently found, then disappear back into the woodwork until Wednesday. I should be caught up by then and will resume my discussion here about process design and implementation, and will begin my discussion of the Tarrani-Zarate Model in our sister weblog, Postcards from the Revolution.

The testing and reliability documents are:

• 28 Best Practices in Software Testing
• Estimating Defect Density During Test Coverage
• Relationship Between Test Coverage and Reliability
• Software Reliability Handbook

Also of interest to software testing and QA professionals is Security Aspects of XML and Web Services, which provides a brief look at the considerations from which you can derive test cases.

If you want to know more about who we are visit our TEAM Zarate-Tarrani page. Until Wednesday, best regards from Tustin, California.