TechWell Contributor

Seems like everyone is talking about DevOps these days. But what is DevOps, and where can you go to learn more about how it affects you and your organization? Join us at DevOps Conference West to find out how to implement DevOps from some of the industry pros who have been part of the movement from its inception.

This template helps to depict the risks in a graphical form, which should be easy to understand.

You can’t force a garden to grow, and you can’t force new processes to work. However, like the gardener who prepares and maintains a garden for optimal plant growth, you can use a planned, organic approach to lead your processes more successfully.

The demand for software environments has increased as more organizations use agile software development practices and are required to provide a fast turnaround of deliverable IT projects. Effective environment management improves the quality, availability, and efficiency of the environments in order to meet milestones, as well as ultimately reducing both the time to market and costs.

Service-oriented architecture offers software testers an opportunity to engage stakeholders early and often. Before you dive in, prepare your testing practices to handle the potential challenges of SOA.

Shvetha Soundararajan and Dr. James D. Arthur write that the agile philosophy provides an organization or a team with the flexibility to adopt a selected subset of principles and practices. However, more often than not, these customized approaches fail to reflect the agile principles associated with the practices.

An iterative agile approach improves the quality and production time for software projects of all scope and size. Learn how this "evolutionary" method improves both development and testing through open lines of communication and collaboration.

Russell Pannone and Geoffrey Bourne write that at first glance, a User Story looks simple, almost trivial. However, it contains the essence of the project deliverables. It describes the who, the what, and the why of every piece of delivered functionality.

This white papte provides overview of how to implement a hybrid test automation framework using QTP as the example. 

As companies focus on tuning their IT environment on rapid delivery of business value, more and more projects and initiatives within organizations are looking at the entire value chain of software production.

Whether under the trendy name of Devops, via integrated project teams or as part of the introduction of new development methodologies like Agile or infrastructure technologies such as cloud, there is a growing awareness of the need for automated, reliable and flexible deployment procedures.

Russell Pannone writes that knowing what comes before the writing of stories, what comes after the writing of stories, and who is going to consume the stories sets the context for the form and substance of a story.

Russell Pannone writes that there is inherent uncertainty and complexity in system-software development; you just don’t know what you don’t know. In agile and lean, accuracy (the measure of bias) and precision (the measure of spread) are very important when making a commitment for what you are going to get done in an iteration, but not so important when making an estimate for how long you think it will take you to develop and deliver the entire product.

We often come across situations wherein software release package is delivered to the testing team toward the end of emergency-fix/release schedules. Project stakeholders anticipate the high-quality software to ship without a breach in project schedule. In such cases, traditional SDLC models such as waterfall model, V-model, etc. don’t work due to the hierarchal form for development and testing phases. The testing approach outlined here provides a practical way of bringing such situations under control and keeping software on schedule without compromising quality.

I have a serious reservation about writing any kind of article wherein I prognosticate. I’m not worried I’ll be wrong: in fact, it’s almost certain that the opposite of whatever I wish for will actually transpire. This phenomenon is, at least, deterministic.

All of my predictions are based around a truth that I believe to be incontrovertible: the pace of innovation in business is accelerating, and the timespan to arbitrage each individual new opportunity is shrinking. Unfortunately, the capability to provide a quality solution to take advantage of any given opportunity remains maddeningly constant.

Every project measures progress using metrics (or at least should). Agile is no exception and powerful techniques exist within agile to track and measure your project’s progress. However, agile goes a step further by regularly using metrics to adapt and improve with the constant goal of how we can be better today.

We live in a very dynamic industry, and spend a lot of time throughout the year talking with customers, analysts and other virtualization vendors, trying to get a handle on how the market is shifting, and how market needs are changing over time.

At this time every year this activity intensifies as market leaders put their reputations on the line and make their own predictions for the new year.

Embotics has been doing this now since 2007, and has a pretty good track record when it comes to our predictions.  Although any market analyst will tell you that past success is no guarantee when it comes to predicting the future.  The market usually finds a way to humble us all.

Welcome to the second article in this two part series. Last month we looked at some of the problems that are commonly associated with Agile Methods when they are viewed in the context of process rigor. We saw that a reconciliation between emergent and prescriptive disciplines can be achieved via a model of orthogonal standards and frameworks. We contrasted that model with the more commonly assumed “continuum” hypothesis, which locates predictive and emergent processes at opposite ends of a methodological spectrum.

This month we will explore in more detail the remedial, standards-based approach adopted by Codeworks DEV. We’ll show how a specialised, tool-supported, configurable toolset can be used to leverage Agile Methods across multiple PRINCE2 projects at both delivery and programme levels.

In this series, I shall be examining the twelve principles of the Agile Manifesto, to tell you why they exist, for they did not appear out of thin air and are therefore in response to some need that we had or have. In the process, I shall also tell you why most of these principles are overly idealistic in their expression and what I think they really ought to say. I am not trying to tell anybody what is right or wrong, this is not a morality debate. I have a great deal of admiration for the ideals that are expressed in the twelve principles (or most of them anyway) it is just that they are misstated and are therefore widely misunderstood.

For last few years or so, I have seen significant improvement in the field of configuration management. Globally many organizations realize its importance and take maximum advantage by adopting best practices and standards to accelerate their business performance. ‘Configuration Management’ plays an important role in any lifecycle of a project and directly impacts the company’s business.

Statement of the problem
It has been more than 10 years since The Office of Management and Budget (OMB) issued Circular A-119 (Revised) directing federal agencies to use voluntary consensus standards, both domestic and international, in its regulatory and procurement activities. This circular defined voluntary consensus standards as having the following attributes: openness; balance of interest; due process; an appeals process; and consensus. Standards that meet these criteria include ISO, IEEE, and ANSI standards. It was expected that the agencies, including the Department of Defense, would cease using their own agency-specific standards which were often modeled after the proprietary standards of the contractors hired to develop those standards.

The waterfall style of development is so deeply engrained into the culture of medical companies that most can’t imagine anything else being used to develop software that has power over human life.

However I argue that precisely because of patient safety, medical device companies in particular need to adopt agile practices. I’ve seen too many bloated medical device project fail or limp across the finish line for causes that can be directly linked to the waterfall method. Specifically:

In addition to the efficiency improvements you expect from automated testing tools, you can-and should-expect them to provide valuable metrics to help manage your testing effort. By exploiting the programmability of automation tools, you can support the measurement and reporting aspects of your department. Learn how Jack Frank employs these tools with minimal effort to create test execution status reports, coverage metrics, and other key management reports. Learn what measurement data your automation tool needs to log for later reporting. See examples of the operational reports his automation tools generate, including run/re-run/not run, pass/fail, percent complete, and percent of overall system tested. Take with you examples of senior management reports, including Jack's favorite, "My Bosses' Boss Test Status Report"- names will be changed to hide the guilty. Regardless of the automation tool used in your development department, you, too, can simplify your reporting and more quickly

Your developers and designers often work on projects simultaneously from around the world. They need to modify the same files, make updates, and deploy multiple versions of the website or code across different sites. All the while, you hope they won’t cross wires, lose track of versions, or overwrite each others’ changes, any which scenario might set your upcoming release or project delivery date back by days. Sound familiar?

We have seen software development evolve from ad hoc to CMMI, to Unified Process, to Agile, to Lean, to what next. Why the evolution? Agile has become the mainstream software development method today. So what? What have we been missing? What are we searching for? In my opinion, it is the quest and delivery of a high quality product. We should strive for quality being non-negotiable. Build something without an emphasis on quality and you are building on a poor foundation that will eventually lead to collapse and result in a final product with little to no commercial or operational value.

What are leading development organizations doing to increase innovation, agility and embrace new technologies? The answer: Distributed multi-source development

Large software projects that are late. Missed schedules. Budget over-runs.

These aren’t pleasant challenges to manage, yet they are hallmarks of traditional waterfall software development methodologies. This common approach to creating software is yielding to two powerful approaches to development: distributed development using Agile methodologies, and multi-source development, combining closed source with free and open source components.

You won't always get along with every coworker in your office, so what should you do to ease office tension when conflict arises? This article offers advice on how to manage conflict in a respectful and productive way.

This article discusses the differences between the internationalization and localization of software products for the global market. It provides an overview of the three areas of localization testing including localization UI testing, localization functional testing, and translation testing. Understanding the different processes is useful for any company and tester involved in the globalization of software products.

It is a well known fact that all applications are different; all application development teams are different. So, why should we expect application lifecycle management to be fixed? There is no such thing as “one size fits all.” Yet, it is also common sense that there must be something in common, as otherwise there is absolutely no way to learn from experience and mistakes. The challenge is then to find a middle ground that is easy to communicate to the development team and stakeholders.

In a Forrester’s report, The Changing Face Of Application Life-Cycle Management, nearly one-third of enterprises are already using application lifecycle management (ALM) processes and tools, and almost half are aware of it But in conversations with user companies, we find that even those familiar with the term are often hard-pressed to define it.

Release planning is more than just stuffing the highest ranked stories into iteration buckets. To be meaningful the whole team needs to participate. Lightweight risk management techniques are not orthogonal to an agile approach They can help proactively address previously hidden concerns and the planning process benefits all-around from shared dialog on release-impacting risks.

Dear Readers,

Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.

One of the key purposes and benefits of Agile development processes (“Agile”) is that they emphasize working software as the primary measure of progress. To ensure that the current state of the software is working, every iteration includes unit and acceptance testing.

Many organizations report that, following the adoption of Agile, the quality of their released systems has been improved.

Users want mobile applications to be simple and fast. Just one nagging bug can spoil the entire experience. And with so much competition in this space, if users don't have an excellent experience with your application, they will switch to a rival product faster than you can say "There's an app for that." This paper highlights some of the areas where the testing of mobile device applications differs from testing desktop and regular Web applications.

Sometimes, the best answer is to rephrase the question. This was the approach that one of our biggest customers took when undertaking a new effort to improve their Release Engineering process. They first asked themselves: How can we make the process of making products faster, more reliable, and more efficient? It’s worth pausing to understand what the process is today before thinking about improving it. Whether managed by a dedicated team or not, Release Engineering is the part of a software development organization that’s responsible for actually converting the millions of lines of carefully crafted source code into a useful software product or service for the end-user. More interestingly, it must also be able to show definitively what went into a release should (when) the need to modify it arises.

An enterprise test lab provides a stable, independent testing environment that leverages your investment in equipment, software, and people. These labs are often built without an analysis of the architecture needed for an effective test lab. Learn how to build or improve your enterprise test lab and make it more adaptable without large investments in time or materials. With an enterprise test lab in place, you can improve the reliability of the end-to-end user experience in production and reduce overall costs at the same time.

Coaching and training are indispensable to Agile transformations. This can be difficult for some organizations to accept.Agile frameworks are simple to understand, but there are many nuances to handling the complexities involved in an Agile transformation.While it is often helpful to tap into outside resources (books, websites, courses or consultants), the organization will need someone who understands the subtleties of Agile transformations and the context of the organization to make the transition as successful as possible.We refer to this role as the “internal Agile coach” and we often encourage clients to identify one or more such individuals as the organization's need for Agile knowledge and understanding grows. Being an Agile coach requires a wide range of human qualities, skills and experience, and selecting one for the company should be done carefully.In this article, we discuss when you need an Agile coach, what an Agile coach does, and a few tips on how you might create your own internal Agile coach.

If software development is about wiring code, then coaching is about re-wiring the neurons in each practitioners head and re-wiring their relationships. Yes, coaching is about changing people. You cannot expect a one-size fit all solution, so you need to adapt the recommended practices and approach. This paper discusses how to work with people, how to manage the coaching progress and setting objectives and expectations. This paper also talks about coaching not being just about helping the team learn, but also for you to learn and grow. You have to be agile to coach agile.

Organizations eager to solve the problems they see in their projects or processes often decide to adopt Scrum in the belief that it will immediate solve all those problems. Although Scrum can and often does resolve some problems immediately, it also has the potential to expose or exacerbate other existing problems and can even appear to create a few problems of its own.

In some cases, this can be seen to be a “failure” of Scrum, even when implemented by an organization that was initially enthusiastic and determined. This perceived failure can cost the organization considerable time and money if the Scrum team continues along the same path they are on, despite the unresolved problems. These costs, as well as frustrations and even pressures from inside or outside the Scrum team can cause Scrum to be abandoned without ever demonstrating its full potential.

What is the Purpose of Coaching?

In our work environments and personal lives we’re always looking to make clear, thoughtful choices, speak them clearly, and execute them in effective ways. We want to optimize our time and energies to create valuable outcomes. All this can happen spontaneously and without a plan, but with foresight to think and plan before taking actions, especially for larger goals, there’s a higher probability for getting quicker and more reliable results.

Let the Fun Begin!

As children, we learn through play. Because play is so much fun, it creates a virtuous circle where we play and learn. As adults, with the help of educational or “learning” games, the lucky ones among us find ourselves playing to learn once again. Judging by the popularity of learning games, we can still learn a lot through play. For some, it may even be the best way to learn.

Usability testing of early GUI designs with paper prototypes validates that you are building the right applications for your customers. This low-cost, high-impact practice allows you to rapidly evolve the GUI interface and find many design bugs early in the development process before coding begins. With this process, you can get external customers and internal users actively involved in designing and testing the GUI with tools they can easily manipulate. Based on project experiences at The MathWorks, Inc., you will learn how to move from the paper prototype to a coded GUI and a set of automated tests. In addition, you will learn to develop user documentation while working back and forth between the GUI and the test plan to clarify design choices.

The CEO of a financial services company had blocked off a day to take his management team offsite for a dedicated session focused on using agile to run the organization. After devoting the first half of the day to understanding agile practices and principles, the balance of the day focused on taking the specific initiatives and goals of this financial services company and translating them into tangible stories. These stories could be used to populate the company’s new Kanban board, one of the tools they would use to begin applying what they learned.

Jim sat in his manager’s office about to have his 6-month review. His boss seemed to have that look on his face. A look he’d seen before.

“Jim, I’d like to say your work is outstanding, but while we’ve been pleased with your project outcomes, your approach to your work needs improvement.”

Jim squirmed in his seat and tried to prepare himself for what would probably mean another layoff.

By Kelley Horton amp; Guy Beaver

Background

The Premier healthcare alliance brings nationwide knowledge to improve local healthcare. It does this by providing solutions to collect and analyze clinical and financial data from its more than 2,200 member hospitals and 64,000 non acute-care members. By doing so, Premier unites a fragmented, chaotic and inefficient healthcare system to enable hospitals to provide patients with reliably high-quality healthcare at the lowest cost. Premier uses facts to determine the best practices and products that drive the best patient outcomes.

Jez Humble is the build and release principal for ThoughtWorks Studios and product manager for ThoughtWorks' release management and continuous integration tool Cruise. He's co-written a book that will hit shelves this year. In this interview, Jez talks about continuous delivery, collaboration obstacles, and the value of defining risk.

Estimation can be one of the most difficult parts of a project, especially early in the project. Fortunately, the requirements creation process can lend insight into the length and scope of a project.

Having troubles introducing agile development on your custom software development projects? Why not try moving to it gradually? One of the big ‘problems’ with Scrum is that project-related issues come to the surface early because the team must deliver potentially release-able software within a month. Those issues in combination can seem insurmountable to those new to Scrum.

In today’s work environments, research proves that distributed Scrum teams can achieve the same quality results as co-located teams, but relationships, communication and culture play important roles in the latter.

About Scrum

Since its inception in 1993, Scrum has become a more and more popular software development framework among organizations. In fact, a Forrester research study, conducted in the fourth quarter of 2008 discovered that more than half of the 2,227 surveyed software organizations take advantage of some form of agile methodology. Additionally, of all the agile methods that are being utilized, Scrum is by far the most popular model.

This article briefly describes the ELF structure as well as some principles of working with such libraries. This knowledge is used to implement intercepting function calls from one library to another.

Requirements gathering is one of the most important tasks to a successful project. Good domain knowledge coupled with tool usage helps in conveying the same communication to stakeholders, designers, developers, and the testing team. This article provides a high-level review on requirements gathering and then mainly focuses on how IBM Rational Software Architect is used to gather requirements.

Sensitive data in non-production environments is rarely held to the same security standards as production data. The inability to protect sensitive data in test environments keeps many companies from leveraging the cost savings of outsourcing and offshoring. This whitepaper focuses on protecting sensitive data in test environments.

Agile embraces the concept of self-organizing teams but they are inherently unstable and are only successful when the ‘Leadership – Self-Management’ dilemma is understood and dealt with. Too much central control destroys agility, inhibits creativity and resists change. Too much self-management leads to chaos and anarchy and destroys a team. A successful Agile Team needs to operate as far along the continuum towards self-management as it can, without tipping over into chaos. You can’t just eliminate the PM role and say to a software development team, “OK, you’re now an Agile Team – you need to self-organize”. This is a recipe for failure, and one of the reasons why many organizations resist the Agile approach.

Even before written history, mankind has followed methods to invent, build, and use tools. As our tools have evolved so have our methods, and in today's software industry there are lots of articulations and communities built around software development methodologies. Despite the zealous beliefs within some of these communities, no single method is the silver bullet or the one truth from which to engineer and craft software in all contexts.

This article is mainly for developers, yet it doesn't cover specific languages or technology. The author details some tools that can help you learn the application's internal structure. Also included is an example of hook lib code, but it doesn't require deep development knowledge to understand.

Naysawn Naderi, a program manager at Microsoft, played an integral role in the R&D process of defining and developing the recently released Microsoft Test Manager 2010. In this interview, an excerpt of which originally appeared in the Sticky ToolLook eNewsletter, Naysawn discusses the requirements for and applications of software testing tools in manual testing.

This article includes a description of a simple unhooker that restores original SST hooked by unknown rootkits, which hide some services and processes.

Project management has contributed diverse triangles as it has evolved. From the traditional project triangle to the agile inverted triangle and, recently, the agile triangle. In this article, I am proposing going one step beyond the agile triangle by taking into consideration lean thinking to add a fourth element, specifically that of design, to form the lean-agile prism.

Estimating Projects give people the fits. On one hand, you have to know when things are going to get done and how much they are going to cost. On the other hand, estimating projects looks a lot like magic from the outside.

I've been successfully estimating and teaching people how to estimate projects for a long time, and if you’ve read Part 1 in this series, you're ready for some tips and tricks of estimating.

Test-driven development (TDD) is a practice associated with a number of Agile flavors. It has become an increasingly popular method for integrating quality into software development at an early stage of the project lifecycle. In this article John Reber asks the question, Which members of the project team should own the tools that are driving the automated testing process within TDD? Are they now solely developer tools or should the testers be the owners?

This article describes an easy way to set up system-wide global API hooks. It uses AppInit_DLLs registry key for DLL injection and Mhook library for API hooking. To illustrate this technique you'll learn how to easily hide calc.exe from the list of running processes.

This article describes the first steps in setting up QT, Visual Studio, and FireBird. This article may be useful for those who just start working with database FireBird, which is usually embedded by the QT provider, and to developers who have also just start working with QT.

Does Quality Management have a place in agile product (system-software) development and delivery?

I buy new cars infrequently, typically every 10 to 12 years. So when I bought a new car in 2003 I was surprised at the many advances in technology since I’d purchased my previous car, a 1993 Honda. One advance I was particularly pleased with was a sensor that automatically detects low air pressure in my tires. It is sometimes hard to tell by looking at a tire if its pressure is low, and checking tires manually is a dirty job, so I did it infrequently. A continuous test of tire pressure was, I thought, a tremendous invention.

During these challenging economic times there is a dramatic increase in the need of organizations to adapt the software delivery lifecycle processes to the rapid changes often imposed on them. Leadership is making the decision to transition its development organization – not than just small teams but large numbers of engineers, working on a broad portfolio of development projects from many different locations around the world — to a more agile approach as part of an effort to vastly improve performance, be more responsive to customers and improve quality. However, there are many challenges that an established software organization faces when shifting to Agile.

Most sprint planning meetings I have attended were fun. The ones that weren’t involved a poorly groomed product backlog, whose high-priority items were not workable, not ready to be pulled into the sprint. When the backlog hasn’t been prepared prior to the meeting, the product owner and team often carry out impromptu grooming activities. These consume valuable planning time and usually result in poor requirements and weak commitments. Plus, everyone is fed up and exhausted by the end of the meeting. As a consequence, the product backlog items that are likely to be worked on in the next sprint have to be prepared prior to each sprint planning meeting. Although it is the product owner’s job to make sure that the work gets done, preparing the product backlog should be teamwork involving the product owner, ScrumMaster and team. We begin the preparation work by choosing a sprint goal.

This paper and the models it uses are intended to help software organizations determine an optimal combination of defect containment methods and resource allocation. These models provide a mechanism to forecast the consequences of alternative assumptions and strategies in terms of both cost in person months and delivered quality measured by "Total Containment Effectiveness"-TCE, i.e., the estimated percentage of defects removed before software release to customers

This fictional diary looks at the experience of an agile QA during a single iteration, sharing some of the scenarios, questions, queries, and successes typically encountered by an agile test team. Some of the issues touched on in this first part include estimations, TDD, exploratory testing, team size, tester-developer ratios, relationships with other team members, and sign-offs.

Discover ways to hide applications within a Windows operating system in this paper. The approaches described benefit corporate security systems development when hiding system agents and preventing users from switching them off. This article is also useful for those who research harmful software and want to build an adequate answer for such threats.

I developed and use a very successful performance testing methodology, which has baseline testing as an important part of the methodology. Proper baseline testing saves a lot of time on performance testing projects. This article covers the how, why, and what of baseline testing.

While Agile methodologies have made tremendous advances in programming circles, build and release management teams have traditionally shied away from a “full agile” approach. In informal polling of Build Engineers, I found only one team outside of my own that ran an Agile shop; while there are many out there who do, there are tender points that need special consideration.

Concurrent testing is the concept that as software is being developed, it is also being tested. Concurrent testing can be done in several ways; one of the most common is to perform testing at the system level. As a development team completes coding requirements for an application or system, this required code becomes testable, while other team members can execute test cases against the completed code.

The agile methodology, like many concepts, is based on an “ideal” setting or environment. In the agile domain this usually constitutes a 100% co-located team of generalists who have unfettered access to the primary business stakeholder. Working in an ideal environment makes sense when you are describing theory, but organizations can find this perfect environment unachievable due to basic business constraints: resource skill sets, location, and time allocation. These constraints present barriers to agile adoption, can hinder productivity, cause frustration amongst the team, and can lead to project failure.

Though Microsoft's Office Clipboard is one of the fundamental parts of the Windows operating system, there is little information about how it works, especially in the low level. In this article, Vladimir explains the Clipboard internals by showing how you can forbid access to it. He simplified the task as much as possible to focus on the most important parts.

A handful of years ago, some of my clients began to ask me, “How are we doing?” My replies were always something like, “You’re doing pretty well at pair programming, and I like how teams have shifted from writing requirements documents to talking about user stories. But teams really haven’t embraced the idea of automated testing yet, and that’s where we need to focus most.” But this wasn’t the type of answer they wanted; they wanted to know, “How are we doing compared to our competition?”

Back in the 90’s self-managed teams were all the rage but they had a high rate of failure mainly because team members lacked people skills. These ideas of self-managed teams were borrowed by the Agile movement when in 2001 they formulated a ‘new’ way of working, based on Agile principles. However, self-managed teams only work well when team members understand a lot about human behavior and why people do the things they do!

This tutorial will show you how to develop a simple file system filter driver. The demo driver will print the names of opening files to debug output. The article requires basic Windows driver and C/C++ knowledge.

Use cases describe typical transactions between the user and the software. This paper describes a new sizing methodology based on use cases. This methodology enables product managers to use available information to perform estimates earlier in the software project life cycle before architecture and implementation decisions are made, as well as providing a framework for capturing historical data to facilitate better future estimates.

One of the first questions we get when implementing and training agility in organizations is about accounting. So much of what happens in an organization revolves around the numbers -- risk/reward, investment/return, burn-rate, etc. Many times developers and technology management gets wrapped up in all the goodness of change and then we forget to bring the accounting folks along.

You do not do Agile, you are Agile. Agile is not a process or methodology. There is no one-size-fits all recipe for becoming or being agile. In fewer than 700 words (with the aid of illustrations), the author offers advice on how to get started in your journey to become agile.

This article describes the protocol of data exchange that is the modification of the well-known OBEX protocol used in the GSM Samsung phones from the SHP family (MOBEX). The described modification of this protocol lets you write data to the phone and get and save data from the phone.

This article describes the process of initial configuration and basic work with the Palm Web OS on a lower level than what's described in the Palm SDK documents. The author also discusses how to install and configure Mojo SDK and how to work with FTP on Palm Pre.

Estimating time is one of the most challenging aspects of Agile. To deliver quality products on time and according to scope not only requires a talented team but also a consistently clear view of the work effort and progress throughout the sprint.

If you're like me, validating row upon row of data lists is sometimes a time-consuming and tedious but necessary task--not to mention highly error-prone as the day or week drags on. There has to be a way to make it easier (and not so prone to errors).

As the economy is deteriorated by financial crisis, many stakeholders request that CEOs retain a company's market share and position. In order to reduce its cost and increase business opportunities and competition, a company should use CoQ improvements to increase productivity gains through quality framework and business model. In this paper, the author discusses how to use common QA framework and business model to help a company retain its market position and keep cost reduction low.

The modern world of systems/software product development and delivery presupposes we work faster and better, do more with less, change continuously, and invent new ways of working. The modern formula for work appears to be: More Success + Greater Speed + Fewer Resources + Constant Uncertainty + Increased Competition + Quicker Time to Market. Mastering the art of agile/lean systems and software product development and delivery requires you ask yourself, "Do I really understand both the technical and non-technical imperatives associated with this undertaking?" This article takes a look at mastering the art of agile/lean system and software product development and delivery; focusing on change.

In this Sticky ToolLook interview, Seapine Software's Paula Rome who takes a closer look at the relationships between requirements, test cases, and traceability in a test plan.

This technical paper augments the official IBM documentation as it is intended for IBM Rational ClearCase and ClearQuest administrators. It may also be useful for administrators of other IBM Rational brand products.

This article is devoted to the embedded Firebird database usage and also the development of a C++ wrapper for this database.

This paper defines some commonly used code coverage measures and discusses their strengths, weaknesses, and the relationship between measures. Examples are used to illustrate some measures and to indicate common traps and pitfalls. Light is shed on the confusing nomenclature in the area of code coverage: different names for the same measure; same name for different measures. Finally, recommendations for the usage of code coverage are given.

This article describes a sample parser of reg files using the Boost Spirit Parser Framework. The main aim of this article is to share the experience, and that's why here, the author shows not so much the solution for the concrete task or the usage of the concrete technology as the way the development process goes. In particular, he discusses why he uses the curtain libraries.

Computer software companies have taken various steps and created different tools to improve the quality of their product development processes and thereby increase their customer satisfaction. Software process improvements combined with the "Balanced Scorecard" is one technique for improving quality that has gained wide acceptance among software developers. This article highlights the usefulness of these techniques and their advantages to small software development companies.

In this article, Victor explains how he made his algorithms work faster using low-level optimization of memory allocation in C++.

Is it just pushing up developer rates and doubling demand?

The cynic in me applauds the genius of the global developer community for inventing a way of working that requires twice the number of people to do the same amount of work – Pair Programming. Doubling demand on XP projects means more work for developers and reduces the pool available for traditional projects – rates go up and more jobs are secured. Is this the same genius as those 70’s marketing execs that added “step 3 - repeat” to double shampoo consumption and therefore sales overnight or are there genuine productivity gains to be had for consultancies and customers? I said I was being cynical, but there is some truth in this and it is a view held by some of those that pay the bills, customers.

Scrum Tapped for Mining Industry

Mankind has, and always will try to understand its environment. In the last century, radar technology has allowed individuals to track vehicles, ships, planes, and even space shuttles and stars. With advances in sonar, people now have the ability to imagine a journey to space, or explore the mysteries of the sea. With the right scientific equipment, scientists can even witness new life and see it evolve. In the mining industry, the ability to identify and assess the world of solids is paramount.

This article describes a detailed procedure for installing a new web application on an existing IIS website, when Wix3 is used to create the msi file. This can be a common requirement in a large deployment. However, I find it's a lot of work to actually get it done,

This article was written for developers who usually create their applications in high-level languages such as C, C++, or Java, but faced with the necessity to develop something at low-level. We will consider low-level programming on the example of working at system loading.

This article is devoted to the question of working with services and applications in Windows Vista. In particular, Yuri considers how to start an interactive, user-level application from the service and how to organize the data exchange between the service and applications. Solutions are given both for C++ and C#. This article might be useful for those who deal with the task of organizing the interaction between the service and the application on Windows Vista using both managed and native code.

In many situations when we create applications for different embedded systems or mobile platforms, we can't develop all parts of the product using managed code only. In this article we will review some aspects of using data types and ways of using them during marshalling data to and from unmanaged code.

Continued Delivery of High Values as Systems Age

Many software developers have to deal with legacy code at some point during their careers. Seemingly simple changes are turned into frustrating endeavors: Code that is hard to read and unnecessarily complex. Test scripts and requirements are lacking, and at the same time are out of sync with the existing system. The build is cryptic, minimally sufficient, and difficult to successfully configure and execute. It is almost impossible to find the proper place to make a requested change without breaking unexpected portions of the application. The people who originally worked on the application are long gone.

Open source keyword test automation framework changes the conversation in automation from building automation tools to using tools for testing applications.

Implementing process change is a risky business, fraught with uncertainty and unknown cost. Process simulation modeling can help you zero in on the changes that will deliver a positive ROI.

As SCM professionals, we want to not only work on software construction and release engineering; we want to help software organizations iterate, release, and work as efficiently as possible.  A true SCM professional will not only work on Build and Release Engineering, but also try to remove all roadblocks to software development and software engineering.  So instead of focusing on a tool in particular, I'm going to discuss how the SCM professional can introduce a tool into a development environment.

Much has been written about the commonality or even the lack of it between Agile and CMM. CMM claims to be a flexible model that can be tailored and adapted to many life cycles. The continued discussion is evident enough that it is not sufficient to compare practice to practice and arrive at any reasonable conclusion about their overall compatibility. The one difference that seems to have earned consensus amongst most of the published literature on the subject is "the people aspect" of these models. 

While working with Product Owners over the years I have learned some rules of thumb that help make their Product Backlogs more manageable. Some of these rules of thumb I learned from other people and some were learned through trial and error.

Remember that the statements contained in this article are just rules of thumb intended to help guide your management of a Product Backlog. They are not rules to adhere to no matter what. Always use common sense when applying a rule of thumb to your particular context.

One of the principles in the Agile Manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This principle guides both aspiring and seasoned Agile teams in the pursuit of continuous improvement and can support whatever Agile adoption path an organization may choose. Kent Beck adds observations about this topic.

The title alone should generate imagery ranging from destructive rumors to the macabre. Who are these dead, and who is speaking ill of them? "The dead" are former team members, the ill speakers are those who blame problems on them, and we are taking a critical look at this complaining with just a touch of irony. We are talking about the culture of blaming current problems and challenges on team members who are no long with the team for whatever reason. Almost anyone who has been involved in the software development life cycle has experienced this behavior, and very possibly taken part in it even with the best intentions in mind.

The definition of agile testing can be described as follows: "Testing practice for projects using agile technologies, treating development as the customer of testing and emphasizing a test-first design philosophy. In agile development, testing is integrated throughout the lifecycle, testing the software throughout its development."

Application testing remains a complex endeavor as development and QA managers need to focus on delivering projects on schedule, controlling costs, and ensuring quality. However, meeting these demands is complicated by challenges such as inadequate hardware requirements, lack of time, test coverage limitation and total project cost. Features provided by server virtualization technology can be leveraged in test environments and subsequently reduce the total project cost.

This report focuses on the importance of monitoring during testing. The author draws his thesis from experience and supports his claim with three case studies.

This paper discusses the suitability of the design of experiments (DOE) methodology for storage performance tuning. The DOE estimates the main and interaction effects of three major storage factors viz, cache partition size (CPS), LUN strip size (LSS), and cache segment size (CSS) settings of an enterprise level storage system on the overall storage performance. Other factors influencing performance are kept constant throughout the experiment to minimize experiment duration and complexity. DOE has provided key ideas for effectively analyzing the relationship of storage factors in storage performance tuning.

(This is a Book Excerpt from "Becoming Agile" by Greg Smith and Ahmed Sidky)

Our project backlogs are full of great ideas. In some cases, we get so excited about a great idea that we disregard all the challenges and jump right in to start development. Sometimes we succeed, and sometimes we have to abort.

Many companies struggle when trying to validate a project’s value. Some companies initialize a project without knowing if it’s viable; other companies scrutinize the value of a project for months before making a decision. There are issues with both approaches.

Scrum is unique in that the management method is consistently direct. All communication in authentic Scrum is concise, direct and clear. Scrum encourages responsibility. The daily stand-up meeting actively encourages personal responsibility to execute on specific work, and to be accountable to the Team. The three questions of Scrum are questions related to accountability for specific commitments.

If you are like me, you've been involved in a project that got off track. You may have even sponsored a project that delivered a different result than you intended. If so, please join me on my journey to learn how to mitigate, if not avoid, project teams and sponsors working toward divergent ends.

In this final installment of a three-part series on product owners in the agile enterprise, Dean Leffingwell provides several case study "vignettes", which illustrate how specific agile enterprises found the right people necessary to fill this role, along with some of the unique challenges they faced and the solutions they applied.

Agile is a development strategy that we have worked with for a number of years now. Lately, we've been getting a lot of questions from clients along the lines of: "I've got a project, I want to globally source it, can I use Agile Development?"

Well, that depends.

Friends, by now we’ve all heard the predictions heralding the return of prudence in spending, optimization, needs-versus-wants and the underlying theme of rethinking everything imaginable. Thus, the focus of our effort seems to have an interwoven connection to the care and due diligence we employ as we chart our efforts and manage our expenditures.

Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production. Today, the work depends on the design and creative skills of the knowledge workers that perform it

Software development is currently being "driven". This article finds existing X-Driven Development approaches wanting because they focus on too narrow an aspect of development and, primarily, because they are grounded in the wrong philosophy of what exactly software development "is". An alternative—theorY Driven-Development - YDD—addressing the "essential difficulty" of development is proposed. How YDD represents an evolutionary step for Agile is argued.

As an executive sponsoring the adoption of agile methods, you've already spent dollars for training and coaching. You've talked to the management team and the rest of the organization about the need and rationale for using agile development methods.

But your job isn't over.

Communication and budgetary support are necessary, but not sufficient for your organization to realize the benefits of agile methods.

If you want the transition to succeed you must provide on-going support. The good news is, that doesn't mean you must keep handing over money. The bad news is that what's required of you is much harder than writing a check.

When XDx's Software Group adopted an agile approach to application development, we achieved the fastest development time on any software project in the company's history. While we expected to shorten development time and reduce costs, we discovered that agile provides several hidden benefits. Beyond its value as a software development methodology, our agile platform is a tool that enables and improves communication with our users which has been a key success factor, because user groups have a hard time thinking in the software development terms imposed by the traditional waterfall method of upfront specification. This improved communication has helped everyone to let go of complete up-front specifications and trust the agile process.

This white paper outlines a checklist for graphical user interface (GUI) testing.

Of all the questions you could ask a person, asking them to recount the 'worst mistakes' they have ever made might be one of the touchiest. However, that uneasiness might be  all the more reason TO ask.

In his book, Success through Failure, Henry Petroski explores failure as being essential to learning and ultimately, success: thus debunking the model that only 'success breeds success.'

The following article is an excerpt from "Agile Testing" by Lisa Crispin and Janet Gregory.

Part II

Organizational Challenges

When software development organizations implement agile development, the testing or QA team often takes the longest to make the transition. Independent QA teams have become entrenched in many organizations. When they start to adapt to a new agile organization, they encounter cultural differences that are difficult for them to accept. In Part II, we talk about introducing change and some of the barriers you might encounter when transitioning to agile. Training is a big part of what organizations making the transition need, and it's often forgotten. It's also hard to see how existing processes such as audits and process improvement frameworks will work in the agile environment. Going from an independent QA team to an integrated agile team is a huge change.

Software process experts have long expounded the benefits of test automation in software development, yet few implement and those often fail to gain the expected benefit. With testing vital to the quality and success of a software project, TopCoder's Blake Tolbert shares tips and techniques on implementing a process that can drive large returns from relatively small upfront investment-creating an environment where developers learn from each other and strive to innovate their processes.

Sometimes we call it "version control."  Sometimes we call it "SCM," which stands for either "software configuration management" or "source code management."  Sometimes we call it "source control."  I use all these terms interchangeably and make no distinction between them (for now anyway -- configuration management actually carries more advanced connotations I'll discuss later).

This article covers the deployment of distributed agile best practices on a globally-distributed project for a large telecom vendor. Also covered are the benefits of these practices, such as better collaboration, quality product, and on-time delivery. The document also outlines the challenges and learning from this implementation of distributed agile for a team distributed across US, Europe, and India.

In the software development industry and beyond, the term "agile" is everywhere. But, much like the "organic" food craze, the rise of agile has also been accompanied by considerable head-scratching. What does it mean to be agile? Certainly, not all of the organizations boasting of agile practices can actually be agile? Unfortunately, there isn't a concise definition to encompass the myriad meanings packed into the term. In fact, the definition of agile is so loose that it hardly helps in assessing which organizations are using practices that are truly agile and which are just calling traditional methods by a new name. In part, agile's fuzzy definition has to do with the fact that it is, by definition, an umbrella term: Scrum, XP, DSDM, Crystal and other agile methods have emerged as subsets of the broader "agile." But, even then, those subsets seldom include the concrete processes a team needs when adopting a new management paradigm. In that sense, the term agile has become bankrupt of meaning: It serves more as a marketing buzz word than a defined set of processes. Because organizations require those processes-as a kind of roadmap to management success-Scrum has become the most popular of the agile management methods. But before further discussing how Scrum and its iterative, incremental approach to project management have appealed to teams and organizations alike, it's worth first considering where it came from.

Group characteristics and group dynamics are invisible to most of us. We are not trained to detect them, let alone manage them. Our work is influenced by much more than what we see. This can make project success (and failure) sometimes appear to be random.

Many software engineering teams have adopted Agile. However, teams delivering process change tend to use traditional ‘lifecycle' approaches and have yet to embrace Agile. Why is that? Can the Agile approach be used to implement or facilitate process change?

As Borland evolved over the last 25 years, acquiring companies and shifting business strategies, the delivery organization had become a collection of teams with different cultures, processes, release cycles and levels of performance. The cost structure of the organization wasn't aligned with the strategic objectives of the company, and the teams were struggling to consistently meet delivery goals.

While doing some research for an upcoming article, some thoughts gelled about where Agile Software Development lies on its evolutionary path. I was procrastinating somewhat, and while poking around some aviation-related sites I saw an image of a jet engine used on the current crop of regional jets.

The main goal of software is to automate and simplify what would otherwise be accomplished using a manual process. This gives the users of the software leverage to do more with less. Instead of balancing our checkbook by hand, we can use Quicken to do it faster and more accurately. Instead of maintaining the records of millions of people's financial transactions with paper and pencil, banks use mainframes.

This is the first of many letters from Screwdisk to his protégé Virus[1]. I make no claims to the authenticity or accuracy of these letters, other than they ring true with what I have seen in the field over the last 10 years. Some of what you will read may sound a bit too familiar. It has me wondering if I have ever unknowingly been on a team with Screwdisk or Virus. I have never been able to find out who Virus and Screwdisk really are, but from what I've seen they could have been at many different organizations around the world - maybe even yours.

In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group's ability to execute on the project vision or enterprise strategy.

Agile teams apply several methods that support this. They self-organize around a common goal agreed with the customer. This goal is most often embodied in the set of stories or tasks to be included in the next iteration. A shared definition of "done," a "living" and dynamic backlog and an involved customer all help to remove ambiguity around the goal and keep each iteration adaptable to inevitable changes.

Midway through 2006, members of a small software development group at an engineering center for an oil field services company began having informal conversations about the nature of their work. Among other things, they pondered whether software development is an engineering discipline or a craft; and where to focus improvement efforts. These discussions sparked the interest of many on the team. They searched and came across the Agile Manifesto, which was posted in their work area. The values outlined in the manifesto appealed to the team.

This white paper covers a proven performance-testing methodology that was developed from eight years of experience. This paper covers the six phases of this methodology: Assessment, Planning, Scripting, Execution, Analysis, Report, and Feedback; as well as the advantages of following this methodology.

In this Iterations interview, an excerpt of which was originally published in the April 9, 2008 issue of the Iterations newsletter, Arlo Belshee discusses the concepts of "beginner's mind" and "promiscuous pairing."

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules, and substantially reduce delivered functionality. This article describes how to define requirements in an Agile environment, including a survey of the most popular methodologies used.

This template outlines the key points of a test summary report in the form of fields to insert your project's information. It includes everything you'll need, including: project overview, clarifications, deviations, testing summary, training, release to production, references, conclusions, test case results, defect log, and traceability matrix.  It includes a form to obtain approval for the test summary report.

Witness the incredible speed at which an international giant achieved the pinnacle of CMMI ratings...then learn how your organization can follow in its footsteps!

You probably have read some articles or books about agile process. John Hsieh doesn't intend to be an expert, but rather he's focused on sharing with you when and how to take advantage of what agile has to offer, and how to complement agile with other methodologies so your project has a better chance to be successful. John's discussion is a practical one: Your success is measured by delivering your software applications on time, within budget, and quality.

Lately I've noticed a fair amount of discussion surrounding the utility of task estimation. The question seems to be: is it really useful to estimate the time required to complete tasks, or is it unnecessary and counter productive to estimate such small units of work? If we're already using some form of estimation for stories, is task estimation really all that useful, or is it in fact thinly veiled micro-management?

What happens when your application software change cycle time shrinks from months to hours or days?

Over the past four years, we have overseen the deployment of hundreds of Web business applications all following agile methods. During the course of these projects, we have faced many challenges and found some surprising benefits.

This article describes some of the lessons we have learned and provides advice on how you might overcome some key challenges in your own agile projects.

Leapfrog your competition by following these fool-proof strategies for accelerating process improvement. Discover how Six Sigma and CMMI can work together to bring about effective change within your organization.

The heartbeat of Agile software development is the iteration-the ability to create working, tested, value-delivered code in a short time box. Mastering this skill takes guidance and practice. In this paper, Dean Leffingwell describes the iteration pattern and the activities that a team engages in to meet this key challenge.

Download Rally's white paper and be entered in this months drawing to win a free ipod shuffle.

The use of Agile methods to deliver software can result in shorter delivery timescales, reduced costs, and enhanced quality. This white paper demonstrates how the implementation of automated testing using Borland SilkTest can provide speed, repeatability and accuracy. If you're going Agile, do it right with Borland.

This paper examines the way testing practice organically matures in an organization. An understanding of the natural growth helps an organization baseline understand its current status. It can then plan and strive to skip over certain steps to reach the desired maturity level.

Agile development is getting increased attention from IT professionals all over the world. Agile practices help to overcome many of the challenges in traditional approaches with its emphasis on lightweight processes, flexibility to deal with changing business priorities, short delivery cycles, higher team collaboration, and a host of other benefits. Agile offers a fresh approach to businesses seeking greater agility in their software projects.

Iteration is at the heart of agile development practices. In an agile project you do something, measure your progress, and then use the feedback from the measurement to figure out what to do next. This cycle allows you to follow the Agile Manifesto value Responding to change over following a plan by providing for points in time where you can measure your progress at the project level. Whether your approach to agile is project-focused like Scrum or development-focused, like extreme programming, iteration is what drives an agile project.

It is possible to apply techniques borrowed from social network analysis) to software development teams. Once revealed, social networks can be actively or passively stimulated for the benefit of team formation and cohesion. Agile principles incorporate social network stimulation on an almost subliminal level; this is one of the reasons why agile principles work.

Software isn't hard, thinking is hard!

"The essence of a software entity is a construct of interlocking concepts ... I believe the hard part of building software to be the specification, design, and testing of this conceptual construct ..."

Frederick P. Brooks Jr.

Brooks suggests that the creation of a conceptual construct is the "irreducible essence" of software. Four properties contribute to the difficulty of creating such a construct: complexity, conformity, changeability, and invisibility.

The first part of this article introduced the concept that developing a complex software system was like going on a journey. I contrasted how we plan our journeys through the use of route planning systems against that of an agile journey which is more like using a GPS in our car. I also introduced the idea that we only know when we have reached our journeys end (being completely done) when we have demonstrated that we have fully satisfied the expectations of the customer, our criteria for a successful outcome and that we can use this thinking throughout our project so that each iteration delivers software which can achieve a successful customer outcome.

This paper discusses how data integrity should secure the customer's data and/or processes against unauthorized access. This paper also details how to adopt strong security standards based on the customer and end user's security policy.

Is there any value to positive testing? Some experts say No! I think there is--and here's why...

Data integrity means the product or the service should secure the customer data and processes against unauthorized access. Secondly, it also should comply to local government regulations and any geographic or cultural laws. Thus, along with functional features, its ability to secure the data and the processes of the customer becomes the key elements it must contain for it to be accepted in the global market.

I wish there was a book entitled "How to Write Your First Letter as an Editor", unfortunately there is none that I am aware of, so please bear with me. As the new Editor-in-Chief of the Agile Journal, I would like to introduce myself and tell you a little about where we will be going with the Agile Journal over the next few months.

With more and more scrum'ing and sprinting going on in agile development, let's reflect on the analogy made between Scrum and sports before we take a look at what misunderstandings it may cause within organizations transitioning to agile development practices, in particular Scrum.

With so many corporate developers and IT teams beating a path to Scrum adoption there seems to be a lot of ScrumMaster training (both certified and otherwise) as well as coaching going on these days. Putting aside any worries about people receiving just enough training to be dangerous (e.g. 2-3 day ScrumMaster training is available from many sources) for moment, most of us think this trend towards Scrum and Agile Development is a very positive one indeed. That said, what concerns me the most is what I perceive to be an oversight of the need for product owner selection, investment and support.

Software systems are being delivered to our customers at an ever-increasing rate. How can we keep up with the pace whilst still maintaining the quality of our code? I will demonstrate over a series of three articles how by focusing on the customer throughout our delivery cycle we can deliver reliable working software with confidence, reduce the number of defects, reduce our delivery timescales and ultimately save money. You may think this is nothing new, and that agile development has long since answered this question. However, even in the agile world there are loopholes which allow us to bypass the customer. Leading us to deliver what we think they want, rather than what they were expecting.

With today's economic pressures coupled with a highly competitive business environment, management is aggressively pursuing ways to increase effectiveness and efficiencies at the same time as they strive to improve customer services. For these reasons many organizations are trying to integrate offshore development into the Agile projects. Offshore development has seen tremendous growth in recent years. The efficiencies gained by combining these two methods could be significant, but there are some pot-holes on the road to success.

Quality of project proposals, in terms of the accuracy in efforts as a response to a bid, plays a major role in winning the business. This article highlights important factors to be considered during proposal writing.

If they don't already, all companies should focus on delivering business value. Agile provides a means to maintain this focus.

The author walks you through the details of actually implementing a continuous quality automation infrastructure. He builds up an example that addresses both the key principles and feedback cycles.

I begin this story by declaring up front that I am not an "Agilist" or process evangelist. I am the senior software development executive in a company responsible for delivering products to the marketplace. Like my peers across industries, I am fundamentally held accountable by my company for consistently delivering business results. Process and methodologies are important in delivering this value, but in the eyes of the company they are secondary to meeting the needs of the business.

Becoming more Agile involves significant changes in the way that we work on a day-to-day basis. One of the central reasons that many technology professionals embrace Agility is its best practices which enhance the Quality of an application effort. Agile practices cut straight to the reasons that many projects fail. Of course, many organizations have also seen that adopting Agile practices does not automatically guarantee them improved Quality either. What practices should you focus on to ensure that your development efforts benefit from Agile's wisdom in terms of improved quality and productivity?

Agile is a methodology that is seeing increasingly widespread adoption, and it is easy to understand why - especially if you consider the developer and user view-points. But, for the Test/QA professional an agile approach causes discomfort - In the ideal world they would have a ‘finished' product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counterintuitive. It means that the use of technology and automation are much more difficult, and it requires a new approach to testing, in the same way that it does for the users and the developers.

As Agile software development practices mature and move into the mainstream, it is vital that organizations understand how Agile practices can help you deliver higher quality software. The Agile is a methodology for software development that promotes development iterations, open collaboration, and adaptability throughout the project life-cycle. Currently, the measures within many Agile projects focus on the successful delivery of software. We refer to these as process measures. Software is the end product and while these measures examine the progress through the delivery, there are other critical measures that need to be assessed. This collection of measurements we refer to as results measures. One critical measure that is often overlooked is called stability. That being said, the true measure of quality cannot be measured until after the project is done and the software is in production. I am not talking about improving the defect density.

Each week, I find myself using Jenga, Hasbro's wooden building block game, as an analogy for introducing agile into the enterprise. Few topics are more hotly debated throughout the software development community than how to apply the simple values of agile to big business. Many approaches favor knocking down the entire Jenga tower to start from scratch with an entirely new foundation of values and practices. Others opt for the comfort of traditional management processes, with some agile practices — like pair programming and stand-up meetings — sprinkled on top.

Our discussion of source control must begin by defining the basic terms and describing the basic operations. Let's start by defining two important terms: repository and working folder.

Since the early 90s organizations have searched for ways to accelerate the development and implementation of new business systems. As it turns out, the ability for organizations to rapidly respond to changes in the marketplace, regulatory environment and demand of the customers is a critical competitive advantage. Over the last few years organizations have been experimenting with a new methodology that is thought to provide time savings when it comes to business systems development and implementation. Perhaps the most common methodology being considered is Agile. Agile refers to an approach for software development rather than just a methodology. It is a member of the same class o methodologies as Lean, RUP and Extreme Programming (XP).

Overcoming resistance to change and addressing challenges with distributed Agile requires considerable skills and experience. Agile development practices are incredibly popular, with many developers, because they work well and they add value. Unfortunately, many Agile enthusiasts are unprepared for the challenge of overcoming organizational resistance to change - especially from senior management unwilling to sponsor a methodology which is unfamiliar to them and does not carry the same name recognition as other frameworks such as the CMMI. That's not to say that we should give up and continue to write volumes of requirements "shelf-ware" that is outdated before it is used. Every process improvement effort has its own set of challenges and obstacles to be dealt with. Read on if you would like to explore overcoming resistance to change - the Agile way.

We all know the payoffs that can result from employing the Agile methodology and employing it well: from highly effective self-managed teams, increased flexibility and realtime change management ... to tight quality control and heightened collaboration.

But what happens when you are already doing Agile in-house and then want or need to expand your Agile development circle to include an outsourcing partner that is 5,000 miles away?

How to determine if a developer is "done" with a particular piece of code is often not well defined. As result software development projects can incur significant rework of features previously thought to be completed, and the quality of the overall solution can be compromised in an effort to make amends. For Agile teams in particular, there must be a clear and consistent meaning of "done" and the team must be able to quickly demonstrate it. Here is one way to define and quickly validate what it means to be "done."

As business activities are becoming more mission-critical, it's becoming more important to adopt testing methods that support business objectives. In response, testers are coming up with new testing methodologies and road maps to exceed the expectations of the demands. Automation is one such dimension that help us to migrate up the value-add chain with our customers. The authors of this paper attempt to identify the potential areas of automation and define a framework for efficient test automation.

Rapid prototyping and development techniques combined with Agile development methodologies are pushing the envelope on the best practice of testing early and testing often. Keeping pace with the quick development turn-around and shorter time to market and being adaptive to late changes in requirements requires effective management of quality process. The use of traceability of test artifacts-test cases, test defects, test fixtures-mapped to the requirements-needs, features, use cases and supplementary requirements-as a QA scheduling and planning tool though mentioned in passing and claimed to have been practiced, has been largely overlooked by the industry. This paper looks into such a possibility through the use of a study for software that involves iterative application development practices and tries to bring this aspect of the technique into focus as a QA management tool.

In this article we describe our work with teams that were spread between the US and India, and with the unavoidable cultural difference. We used a facilitated retrospective to discover the most challenging issues in the process and, just as important, to build a team and increase trust between team members. In later work with the teams, we noticed the immediate positive impacts on the people and the process.

At the core of all software solutions are underlying software architectures. The architectures reflect initial assumptions about how products fit together, which features are of value to customers, what are the expected integration points, with which related technologies. As software products find acceptance among customers, and technologies continue to evolve, the creators (vendors) of these solutions eventually find the need to adapt underlying architectures. Agile provides a means of doing this early in the product lifecycle and with continual review that provides the creator with the ability to adapt quickly and effectively to changes is the marketplace.

Electric Cloud, a leading provider of software production management tools, has always employed an iterative, agile approach to its software development. But like many fast-paced technology companies, a script-driven, manual approach and once-daily integration builds could not scale effectively to support its growth. Through a mix of tools and best practices, Electric Cloud was able to deploy an end-to-end build and change management system with fully automated continuous integration (CI). This new software production system has reduced the time Electric Cloud engineers spend on software production by more than 30 percent and has saved the company an estimated $700,000 per year.

Well-formed agile teams can thrive in a direction ideally set by business vision. Unfortunately, many teams are forced into survival by organizations that push work through the team matrix, forcing teams to establish themselves as dependencies. The purpose of this article is to firmly establish the notion of well-formed teams so that guidance patterns for their creation can help organizations to "thrive" instead of "survive."

Ready to catch up (or just start) on your professional reading? Here is what two of your peers have to say about some recently published software books.

Software development is seen as chronically chaotic and complex to the extent that project management can achieve little control over projects or outcome [1, 2]. Recently, we have come into a new era of hope; hope of getting people - real people, users, both naïve and sophisticated - more involved with, more relevant to, and more visible in software development.

The goal of this paper is not to discuss the process, metrics, automation and outsourcing in great detail but to understand them well enough to hopefully find a common sense approach toward a workable solution of today's complex, demanding and ever changing nature of software testing.

There are a lot of tools available to testers. Some good, some not so good. As we use and gain experience with the various test tools, the set of tools in our tool box becomes larger. Having a large set of tools in your toolbox allows you to better adapt to any test situation.

Peter Clark's company started an offshore development team in India—it failed. Peter examines the underlying reasons for that failure.

At some point in the software development lifecycle, regardless of which model you use, we have to make some tough decisions. What defects do we fix? Which should we let go? How do we decide? Triage is one way!

This document highlights some of the SQL coding best practices, which help developers and database administrators optimize the data access layer. These features can be implemented across all RDBMS to achieve best performance results from a database.

Recently there has been a lot of talk on whether we need an Architect on agile teams or not. There have been never-ending discussions on various forums both inside organizations and out in the public questioning the value that an architect can bring to the agile project where the architecture evolves with every iteration. This has led many traditional Architects to scramble for cover and opened gates for a new breed of architect, the Agile Architect. The traditional ivory tower Architects are gradually proving to be the weakest link in the chain for agile projects. 

There are many ways to transition to an agile process. Choosing the approach that is most likely to work best for your organization can be critical to a smooth transition. Through helping hundreds of teams make the transition to agile over the years, I have identified six core patterns that teams use to initiate the transition to agile. These patterns fall into three sets of opposing pairs. You should choose the core pattern from each set that best suits your team or organization:

• Start Small or go All In?

• Technical Practices First or Iterative First?

• Stealth Mode or a Public Display of Agility?

There are many accepted processes and approaches to managing enterprise requirements. These approaches vary from model-focused to document-focused and are well known and practiced by requirements-gathering specialists throughout the business world. The real intent of any enterprise requirements management organization is to accurately capture and manage needs of the business, and organizations are built to create repeatable processes for doing so. However, once the focus shifts toward processes for eliciting and managing requirements, and away from the business goals, problems can arise.

Many times we wish that some magic steps could help in parameterization of scripts in Loadrunner. Here are the basic steps to be followed.

The characteristics of data warehouse applications pose a challenge for any organization planning a data warehouse initiative. How can we be sure that the data is accurate and reliable when there is an enormous amount of it coming from multiple systems with different data structures? To answer this question, this article describes a testing approach that combines practical experience implemented during the testing phase of data warehouse projects.

Business process automation works towards making automation frameworks increasingly meaningful to the functional subject matter experts by involving them in test automation as much as possible, thereby making test automation business driven. This article discusses a tool that can be used in business process automation and some tips on developing a strong and robust automation framework.

Agile teams large or small, co-located or distributed, have one very important common denominator: the absolute imperative that a strong product owner be established before any work begins. Arguably the strongest, or weakest, link in any Agile team is the product owner. At odds with this basic fact is a startling oversight of this role at the outset of many projects. Add to this a multi-site outsourced development team and it's no wonder successful enterprise Agile adoption is slow going. What makes a good product owner? Why is this role critical to the success of any Agile project? How should this role be supported within the team and organization? These fundamental questions will be addressed herein.

To most non-technical people, the mere mention of "IT" can be a real turn off, or result in a roll of the eyes. Although traditionally associated with geeks developing code in a back room, IT - in its very broadest sense - forms the backbone of organizations today, which begs the question: why is there still such a huge communication gap between the IT discipline and the business it powers? This article provides anecdotes and advice for businesses to help them resolve the issues between business and IT, and describes how using Agile methods might just save their relationship.

Several forces in the software industry are combining to dramatically shorten product cycle times for even the largest applications. These forces also shorten the feedback loops on an application's quality, usability, and customer relevance. As feedback loops shorten and the number of software deliveries goes up, it becomes paramount to inform and collaborate with employees, customers, and partners in a community setting.

Several forces in the software industry are combining to dramatically shorten product cycle times for even the largest applications. These forces also shorten the feedback loops on an application's quality, usability, and customer relevance. As feedback loops shorten and the number of software deliveries goes up, it becomes paramount to inform and collaborate with employees, customers, and partners in a community setting.

Agile processes and practices have gained enough attention that both IT businesses and product development organizations are engaging in large Agile implementations. These larger-scale products, programs, and projects are more complex, have more dependencies, and present significant challenges.

Six Sigma tools, which follow the DMAIC methodology and are explained in this paper, could increase testing productivity and improve efficiency during testing. This paper also reviews a case study in which test productivity was improved though the usage of Six Sigma tools and techniques.

NCache lets you cache data closer to your application in the middle-tier so you can reduce expensive trips to the database. This in turn significantly speeds up your application. It also makes it more scalable because the load on your database is reduced allowing it to handle a larger number of clients without any hardware upgrades.

This article has been unpublished because it was a duplicate of an unfinished draft of the article Lean Traceability: a smattering of strategies and solutions (please read the referenced article instead)

Service Desks traditionally serve the operational and production aspects of IT organizations and their respective business units.  However, business services that consist of applications typically start their lifecycle as requirements from the originating business unit, then follow a development lifecycle before entering the operations realm.  This development lifecycle
is commonly a blind spot for service desks manifesting most typically via an incident logged against an application in production requiring maintenance or upgrade work to be completed by development.

This paper describes an approach that leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. All the examples are referred to a CMMI-based process definition but the most of the concepts are applicable also when adopting process models other than CMMI®.

In this article, the author provides a guideline comprised of seven steps involved in the entrance and exit criteria process for system testing. It is not enough to state the criteria within the Master Test Plan. Rather, you must actively participate in defining the activities associated with meeting the criteria, drive towards its successful completion and manage risks if and when they arise. Examples are also provided so that you can tailor them to your specific project.

The authors of this paper present an object-based, keyword-driven framework for J2EE Web-based application testing. They also discuss the benefits of automation testing compared to a test library approach.

Liz Barnett writes that beyond IT, the most frequent adoption of agile processes is found in teams using Scrum for team management. Agile processes won't provide the answers to all of our challenges. But if you dig beneath the surface, you might discover some interesting ways to use these ideas to address complex problems.

In this article the author discusses the time-tested Hub-N-Spoke Release Management process that ensures a holistic view of the code (new or modified) is considered before releasing it into the production environments. This process was used successfully by data management groups of a large financial company. Subsequently the use of this Release Management process resulted in improvements in the code release process.

Many software development organizations are electing to implement Agile development methodologies in order to take advantage of the cost, quality, and time-to-market benefits commonly achieved with this approach. At the same time, these organizations are moving software development offshore to take advantage of greater scalability and quot;round the clockquot; development cycles. However, in combining these two efforts, the highly collaborative nature of Agile is tested as teams are faced with cultural challenges and necessary work habit shifts. If you are considering implementing a Global Agile approach to software development, then it is imperative to focus on an often underappreciated aspect of this initiative: building the right team. This is the most critical step in delivering the benefits of Global Agile development.

This article is about career planning software quality control testing, including defining career milestones within software testing. It is a helpful guide for beginners and others working in the field.

Agile software engineering and agile project management have become more mainstream in recent years with great success. But the benefits from agility should not have to stop there. Instead of initiating a project and letting the team run with it, progress reporting, planning and estimating should translate through all the channels, back to the corporate strategy. That way, executive management or the PMO can continuously balance the vision of the organization. This article will present these concepts for agile portfolio management.

We claim that by exploring the metaphors of Scrum, many of the common confusions and debates surrounding Scrum are easier to understand. It has been our experience that people often reach different conclusions with the same words because they are using different metaphors. Additionally, we have observed that that once people become aware of the differences in their applied metaphors they can see each other's point of view more easily. 

Fast cars, flat-screen television, high definition gaming consoles, and dual core processor equipped laptops: the amenities of modern technology rule us. Computers are an integral part of our lifestyle and work-life, and many people define themselves by their choice of tools to complete tasks. Those interested in implementing agile frameworks are no exception, often voting to use electronic tools before exploring alternatives. This article is meant for the open-minded, ready-to-explorer surrogate who is not afraid of being a low-tech hippie in times of high-tech espresso machines.

Agile development is a process methodology where, at its core, is the ability for developers to share and test changes in software as rapidly as possible in an efficient but disciplined approach. The Continuous Build process is based on manual scripting and therefore is highly redundant and non-adaptive. Continuous Builds that rely on redundant scripts become road blocks for agile teams when attempting to move quickly from code to deployment. Agile developers must recognize the problems of manual scripting and begin moving toward a non-redundant Community Developed approach to managing the Continuous Build. 

Getting Started with Agile Development

Damon Poole, AccuRev Founder and CTO, discusses the keys to, and challenges of, Agile development.

Delivering More Business Value Where Needed

Within the software development community, one of the biggest movements over the past decade has been Agile Development whereby teams adopt practices and attitudes consistent with the now famous Agile Manifesto. Additionally, there has been much discussion over the past four to five years about applying principles from the Theory of Constraints (ToC) and Lean Product Development (Lean) to software development. This has had a tendency to muddy the surrounding waters as teams question whether they  should apply Agile, ToC, or Lean concepts. Are these three approaches mutually exclusive? Is there some hidden magic that can be unlocked by careful application of all three? Isn't it hard enough just trying to be Agile, without also trying to be Lean and ToC-ish? In this article we give an overview of Lean and ToC and show how they can be used in conjunction with Agile practices to focus on an organization's business value. By using elements of Lean, ToC, and Agile together more business value can be delivered with less effort.

The most significant hurdle in adopting agile development is often gaining the acceptance of the business leadership. Business leaders either believe that agile requires too much time, or they are generally apathetic towards the effort. But while business leaders may be difficult to get on board at the beginning, they can be the strongest supporters of the agile process once they see and understand it. Getting them to try it is the hardest part. This article addresses the typical barriers to involving the business side of the house in an agile development approach, and outlines the key steps that Digital Focus has found to be successful in overcoming these barriers.

Let's face it, nowadays going from version 7.0 to version 8.0 means working with a dispersed team of developers who aren't necessarily located in the same corner of the building - if the same corner of the world.

Software development and configuration management are often conducted by professionals in locations distributed about a larger virtual environment.  In fact, the Gartner Group estimates that by 2008, 41 million corporate employees worldwide will work virtually at least one day per week. 

Upgrade path testing, also called upgradation testing, sounds a bit unusual. But testing upgrades is an important part of the software life cycle, and this article explains how it should be done.

Whether you are concerned that your job is going to be shipped to India or feeling safe that the outsourcing craze is calming down, the reality remains that we live in a global economy and more and more companies are beginning to explore ways to creating software in distributed and multicultural environments. The Web and the open source movement have demonstrated that it is not only possible to create quality software in a highly distributed and decentralized manner, but also that it "makes business sense" to do so. This article presents a pragmatic framework for introducing Agile practices and tools to onshore-offshore distributed teams.

In order to stay competitive, IT companies integrate offshoring and outsourcing in their corporate strategies. When these strategies are implemented it is often found that offshoring is full of challenges and much more difficult than expected. This article suggests that the challenges of offshore software development can be met by using agile values, principles, and practices. First the article will present some of the challenges in offshore development, then it will investigate how agile principles and practices have helped offshore development in becoming more competitive by eliminating the challenges usually found in traditional offshore development. However due to the added distance it was found that agile development will run into new challenges. Some challenges, such as time zones, are hard to meet and will impede direct agile communication.

In this article, the author shows how a combination of tools (mostly open source) can be used to implement a test management plan.

Many people think that to large companies Configuration Management is seen solely as a technical role and as a cost burden to the company. The following article explains however some of the financial aspects of the role. These are examples that have occurred during my role as Configuration Manager in several companies. In these roles I have been much
more than just a technician.

Agile Earned Value Management (AgileEVM) offers a simple, lightweight method for integrating the benefits of traditional EVM metrics into your agile software development process without causing "drag" on team productivity. AgileEVM metrics can provide added value for project stakeholders, product and project managers, and Agile team members. In particular, AgileEVM adds a cost reporting component to the Agile toolkit that supports project decision making.

This article acts as a handbook for the newly emerging breed of SOX testers for IT application controls. The article briefs on the basic responsibilities of a SOX consultant, the qualities required and demarcation of tasks between the IT and SOX consultants in an organization. Also the article highlights about setting the expectations right with the IT and SOX teams to enable frictionless working environment.

Testing hidden data is a necessary and important part of the software verification and validation process. The quality of an application must not only be proven through the visible data in the user Interface, but must include the data as it travels through the system. With a few database skills and using the 4-step method described in this report, these tests can be accomplished by the Quality Assurance team.

One of the challenges testing teams face is in organizing and making available an integration test lab infrastructure so that the System Integration Testing (SIT) takes place smoothly. This article provides simple guidelines intended to give valuable inputs (steps) and tips to establish such a test lab.

Health and well-being (HWB) services provider vielife has taken an agile approach to upgrading its Web-based HWB service and management information tool, with the help of Agile consulting firm Valtech. Due to the nature of the agile process, the team was able to make adjustments to development of the next generation portal along the way, adapting to changing business requirements and ensuring that each phase met expectations. As a result, vielife has been able to increase flexibility of the service, has the capacity to deploy more interactive health behavior change programs, and has gained better overall management of the system. This article discusses the project and how vielife has benefited from using agile processes.

In this article, Tapas Kumar Sahoo explains buffer overflows and how to prevent them.

I am the Programme Configuration Manager for the SOA programme for a large UK financial company, which have adopted an SOA approach for creating new services to replace existing
applications.

Part of the problem which I have found when first trying to come up which a Configuration Management strategy, is that normally you can go to the internet and there are lots of articles on a subject in a particular area. However, what I found was that there is very little and what there is, is mostly theoretical even from well established names.

Let's face it, software configuration management can be downright overwhelming, and its
complexity can challenge the most organized project manager. 

When The Standish Group conducted research to analyze the successes and failures of software projects, they found that 8 out of 10 projects are unsuccessful.  Furthermore, nearly a third of all projects are so poorly executed, they are nixed before they are finished. 

Over the last two years BT Exact, British Telecom#39;s IT organization, has been going through a radical organizational transformation. A central plank of this transformation has been BT Exact adoption of an Agile approach for systems delivery. When BT began to look at how you transform an organization of approximately 14,000 people to become an Agile organization, the size and complexity of BT seemed to be an issue. One challenge faced was how to support this size of a transformation from a coaching perspective. That is, how do you leverage a relatively small finite coaching resource so that it can be effective? This article will chart ongoing journey to address the need for Agile coaches and how "jam" proved to be inspiration along the way!

This article describes the necessity of simulation in host-target testing and provides strategies for host-target testing throughout its various phases.

Development teams in companies spend considerable amounts of time, resources and effort to design reliability into the applications they build to support business processes. Ask anyone responsible for delivering products or services about building quality and reliability into their offerings and they'll all tell you the same thing: it's a lot less expensive to build quality and reliability into processes upfront versus fixing problems in the field.

The old adage goes "you cannot manage what you cannot measure". True enough, but where do you start in implementing a measurement program? What information is really important? And, how do you decide what to measure and what will matter to others? 

No one in this audience will disagree that metrics and ongoing analysis is a crucial element in effective software project management. However,  metrics programs do have their
challenges. Let's admit it, metrics can be difficult, time-consuming and challenging to derive. Development managers will relate tales of woe of their teams spinning through cycles to pull out metrics lacking in relevance to the business. This approach to measurement is a thankless exercise that can paralyze the entire project team. 

You can improve the overall quality of a software project through the use of test metrics. Test metrics can be used to track and measure the efficiency, effectiveness, and the success or shortcomings of various activities of a software development project.

The term "Process Facilitator" refers to the people in your organization whose primary responsibility lies in improving the effectiveness of the work that the teams are doing. This responsibility is mainly around the process the teams are using, but also encompasses less tangible aspects of work such as team development, organizational culture change, administrative and technical tools, and working with other Process Facilitators both inside and outside of your organization. Since the role of the Process Facilitator is so broad, it can be difficult to understand and effectively support Process Facilitators who report to you. This article helps you with this challenging task.

Successful extended global development teams have adapted Agile methodologies such as XP, Scrum and DSDM to further improve response to customer needs and time to market. At the same time, they gain rapid knowledge transfer, training, transition planning, goal setting, governance, as well as the comprehensive operational reviews required to achieve results. There can certainly be challenges employing Agile development methodologies in a multi-shore environment.

System verification approaches for high-tech equipment have not scaled in step with increasing technical complexity. While software developers now enjoy numerous tools that offload mundane tasks, QA teams still spend much of their time performing repetitive manual tasks like configuring testbeds, and documenting existing test cases. This paper suggests a new approach to system verification derived from the successes of other industries facing comparable challenges.

Software development organizations have evolved to meet the challenges put forth by ever increasing complexity in both the problem spaces and the technologies applied. Unfortunately, the right people for a project may not all be located in the same city or at the same time.

This template includes team management, test cases, and test and defect status reporting. It can also be used to track a test log, defect log, schedule and effort variance, testing metrics, and traceability matrices. It can accommodate test cases for one hundred modules to a total of 5000 test cases. It also can have test cases for twelve cycles of testing. The test results can be seen in numbers and in graphical formats.

The PMBOK outlines the specific actions required for proper risk management. In this third installment of Michele Sliger's four-part column series, she looks at this risk management process and determines how compliance with the PMBOK practices correspond to activities that an agile team might do.

Today, applications are undeniably the proxies for key business processes.  So, improving application quality drives directly to improving overall business performance.  It's no wonder then that improving application quality and uptime is a top of mind issue for IT managers and executives. 

One of the simplest ways to enhance QA's ability to manage the test process is to put the QA group's Test Cases under CM control. Besides being an industry best practice, putting Test Cases under CM control will also help to qualify your organization for CMM Level 2. Depending on the features and functions of your firm's CM tool, putting Test Cases under CM control can provide the following benefits:

I have been in and around Web Services and Service Oriented Architecture (SOA) for a long time. I have built distributed systems for fifteen or more years. I have scars from the Great Web Service Euphoria of '99 to '01. I have gray hair from dealing with the security and management problems of building real services in real networks. I have followed the standards as they have matured. I have observed and worked with clients as they considered and confronted SOA. Here is my conclusion: real SOA is so complex and organizations are so far from ready for it, that the only sound SOA adoption strategy demands agile program management techniques. Nothing less will suffice to guide and sustain an organization through the SOA evolution.

Because one of the core stated objectives of Service Oriented Architecture (SOA) is to increase business and IT alignment and IT's flexibility in meeting changing business needs, on the surface it would seem that SOA and agile methods are a natural fit.  And within the SOA model of service production, distribution and consumption, use of agile development methods clearly has great opportunity for effectiveness on the consumption side of the equation. However, the approach by which a suite of generally reusable services within an SOA are defined and produced requires a cross-project perspective that could be viewed as running counter to a typical agile development approach. Some amount of up-front architectural thought must go into initial service definition to prevent those services being developed from becoming solely project-centric.  

This topic has in all likelihood been discussed and hammered more than any other CM-related subject.  But it's a good idea to revisit it now and then, especially from another prospective and point-of-view, just to keep it fresh.

This month's theme, "Implementation Methodologies", focuses on many different opinions and viewpoints. During the initial discussions among the Crossroads News writers and our editor, Patrick Egan, there was both confusion and clarification. The confusion was largely semantic, and the clarifications, well they came from many authors' perspectives. In the end, our editor said he wanted to see papers that, "...differentiate between our SCM implementation at the organization level, application level, and project level -(aka, the "Target Level/Audience Method"), and implementation approach." He also indicated that he was interested in subjects that ranged in variety from analysis, to tool selection, to design, to installation, to testing, to training and deployment". I liked that primarily because this directive gives rise to a wide range of perspectives of what implementation methodology means to the practitioners of the software engineering community. Therefore, here is my own viewpoint of what Implementation Methodologies mean to me.

Independent Verification and Validation (IV&V) is fast being recognized as an important step in the software development process to improve quality when building a software system and ensure the delivered product satisfies business user's operational needs. The IV&V assessment and associated recommendations provide management and the project team with actionable advice based on industry standards and best practices. This article details the benefits achieved with IV&V.

Agile over the wire and how to make it work.

In our experience, pure-play Agile development is destined to fail in a global delivery model. The basics of Agile, such as the emphasis on face-to-face communication, close interaction between teams and an adaptive approach to product development, are not possible while engaging an offshore team. However, by injecting process adaptations, Cognizant has successfully enabled some facet of "specially customized" Agile methodologies. In fact, a large percentage of Cognizant's software product innovation services use Agile practices in some form or the other.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Agile Manifesto principle 12)

A cornerstone of agility is the team's commitment to continued reflection and adaptation. For most teams, there is a natural cadence to this process as iterations occur frequently, typically every one to two weeks apart, and releases occur every two to four months. As such, the iteration boundary represents a frequent opportunity for immediate feedback and quick mid-course correction, primarily focused on the team's ability to simultaneously define, code and test new functionality in a time box. At the release boundary, the measures move to those things that reflect the team and the organizations ability to move that functionality from "inventory" to delivered product or system. In this article, we'll describe a set of iteration and release metrics that have been used to good effect by a number of agile teams. In our experience, teams that are effective in using these iteration and release metrics have the best chance to achieve the maximum benefits of agile.

It is apparent that agility works, whatever that may mean. However, many software projects remain artifact-driven and waterfallish. Why is this? The most common excuses are that agility is too developer-centric, that it is too lightweight, and that feedback to business is hard to understand. In particular, many managers in larger companies miss their metrics. In this paper we address this last problem by defining a new metric, Earned Business Value (EBV), that replaces standard Earned Value Analysis (EVA) metrics, and can be calculated in an agile project. Using EBV, teams can gain better understanding of a project's progress and determine when and where to reallocate resources or change course.

A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions). When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wrong with the agile process.

There are several reasons why we may need to merge two modified versions of a file:

• When using "edit-merge-commit" (sometimes called "optimistic locking"), it is possible for two developers to edit the same file at the same time.
• Even if we use "checkout-edit-checkin", we may allow multiple checkouts, resulting once again in the possibility of two developers editing the same file.
• When merging between branches, we may have a situation where the file has been modified in both branches.

The terms version control and configuration management are often used interchangeably, while some view them as separate disciplines. In fact, version control capabilities are a part of a well-defined configuration management process. We will explore these related disciplines and show how they can be applied successfully to problems facing IT professionals today attempting to manage their application infrastructure.

This template will help you determine defect standards for your next project. It includes examples of defiect severity level and fix prioritiy level with proposed definitions for each of the levels.

There is a widespread opinion and popular belief that both low-level testing and unit testing are one in the same. In this article, Kuppuswami Muralidharan Iyer puts forward his views on the subject as to why they are quite different.

Application Development Open Source Strategy with an Architecture-centric Approach Today's software developer, like never before, is blessed with a plethora of sophisticated open source tools and technologies to aid his craft in producing market-worthy applications.  Leveraging these resources together with the developer's business domain knowledge and agile best practices can quickly yield some truly amazing results  To sustain these successes, an application developer must apply an architectural-centric approach in order to realize longevity, flexibility and independence in his application.

The traditional approach to managing productivity is that employees punch a clock – in at 8, out at 5 – and employers must assume work is being done during the intervening hours.  However, the current reality for many, if not most, businesses, is that the traditional approach no longer works.  It has become unclear whether or not work is being accomplished regardless of hours logged at the office.  With the increase in outsourced and offshore teams, many developers are scattered across different states or even different continents and throughout a variety of time zones.  As a result, it’s not possible for a manager to ‘swing by’ a developer’s cube to get a status update on a project or even just to do a quick check that a team member is present and productive.

Michele Sliger understands the turmoil project management practitioners go through in the transition from plan-driven approaches to agile methodologies. Michelle continues her four-part series relating Project Management Institute (PMI) best practices--as identified in the PMBOK--to agile practices.

In today's business climate there exists an ever-increasing demand to achieve more from less. More return from less investment, faster time to market from shrinking resources, higher quality from collapsing timelines. The impact of these pressures on the software development industry has meant that organizations have had to look for new avenues such as offshore development to reduce costs yet still satisfy these increasing demands. Simply incorporating an offshore development strategy to realize lower costs is not a solution. Leveraging the lower cost and resource scalability that an offshore development strategy provides must also include the facilities to enable that capability to produce better results faster.

Part II of II - Seven Additional Practices For Enterprise Agility

In part I of this Article, we noted that the benefits of agile software methods, including faster time to market, better responsiveness to changing customer needs and higher quality are undeniable to those who have mastered these practices. However, these practices have been developed and refined in circumstances characterized by small, co-located teams with ready access to a customer. Can enterprises building applications that require hundreds of distributed team members benefit from these practices, or are they forever doomed to large, late, stage-gate and waterfall-like results?

One of the trends being discussed in business, among vendors and in the analyst community is the importance of automating the functions performed by IT. Growing demands by the business, tight budgets and compliance pressures together accentuate the need for IT to be more agile, efficient and responsive to business stakeholders.

This is the first of a four part series on Subversion (SVN for short). It covers Subversion history and basic overview of most important SVN features. (Part 2 will cover Subversion installation and look at the most popular clients. Part 3 will give you the guided tour of the most frequent Subversion use cases. Finally, Part 4 and will give some hints for the process of migration from other RCSs to Subversion.)

This white paper looks at the prerequisites, stages, and potential return on investment of an automated testing program.

The benefits of agile software methods, including faster time to market, better responsiveness to changing customer requirements and higher application quality are undeniable to those who have mastered these practices. Agile practices, however, have been defined and recommended primarily to small team environments where co-location, ready access to interactive customers and small team size are the defining rule.  Are the benefits of agility to be denied to those larger software enterprises who don't share these simple paradigms? Or can the industry learn from these practices and apply some of the core principles to large scale development of applications that require 100, 200 or even 1,000 distributed team members to achieve?

Test automation has emerged within the software quality assurance (QA) and testing process as a way to save time and provide significant return on investment. However, many organizations are finding that a productive test automation environment is often fraught with challenges. This article compares the challenges against the expectations of what test automation should bring to a project.

Michele Sliger understands the difficulties traditional project management practitioners go through as they transition from plan-driven approaches to newer agile methodologies. In this column, the first in a four-part series, Michele discusses the initial key area of PMBOK: integration management.

High performance of integration builds is one of the keys to risk-free software development. This article discusses simple and advanced approaches towards addressing concerns of performance of integration builds.

Can you reduce a test cycle by testing an application using the best set of test data? And uncover the unknown bugs throughout the application homogeneously with minimal risk? Yes, by using the orthogonal array based testing technique. This article explores its importance to software testing, and how it can help you release high quality products.

There are many published papers, books, and articles that address the need for software security. They explain how we can fight "intruders" from forcing their way into our systems. In this article Harinath Pudipeddi points out a few basic, yet important considerations that an organization must keep in mind while developing applications from a security perspective.

Telling a story with words is one thing--but visualizing a story with pictures is extremely powerful. Smart start-up firms are beginning to develop robust simulations of their software application idea as a way to gain an advantage in this competitive arena–before they start coding. Simulations serve to paint a vivid picture of an idea, bridge communication gaps and enable ideas to get to market faster. How can simulation help you as a start-up company? In this article, the author explains how a robust simulation of a software application idea can help a start-up company in many different ways.

Current software engineering processes face a growing need for a transparent view into change. A transparent view into change is a view that allows accessing essential information about change throughout the application lifecycle, from capturing requirements to building and deploying production binaries. Such transparency is dictated by both natural and administrative needs and helps answer the question of who, why, when, where and how in detail.

The key to successful build management is a foundational commitment to consistency, repeatability, and portability. This is true for small, homogeneous development environments using in-house, scripted build systems, as it is for large, complex environments, where a new class of non-scripted, distributed build-management tool is now available. Build administrators who plan ahead can optimize the process of manual build scripting that will enable significantly more flexible and manageable development environments regardless of platform diversity.

We live in an online, wired world. The digital and physical worlds are so intertwined that almost nothing can happen unless the relevant applications are up and running.  You would think that as software applications become indispensable, they would likewise become more and more dependable. Instead, the rising tide of systems complexity and interdependency are making enterprise application problems inevitable, intractable, and more elusive.

When the United States landed a man on the moon, my wife and I use to engage our friends in fun debates on whether Neil Armstrong really stepped onto the surface of the moon or did he descend onto a huge sound stage just north of Phoenix, AZ. As farfetched as that argument is, in many cases, upper management in many software development organizations are being led to believe that their Eagle has landed at Tranquillity Base when it fact their project is “Lost in Space.” Much of that information is coming from the Configuration Management System (CMS).

The first thing that comes to mind about release management is how frequently releases are made and their levels, i.e. full release or patches. A common understanding of Release Management is that it is the management of introducing controlled items into a production (live) environment. But in reality release management is much more than this. “Release management is the process of planning, building, testing and deploying hardware and software, the version control and storage of software.” (British Educational Communications and Technology Agency, release management, Retrieved from http://www.becta.org.uk/tsas/index.cfm?refsect=ntss&bcsect=default§=release&id=tt5281 ) release management is not just what goes into production but also how something goes into production. It is the complete management of your production environment.

For any good developer, applications are like children. You spend countless hours nurturing them and preparing them for the real world. Sometimes they frustrate you, other times they give you tremendous pleasure. And in the end, you’re just downright proud.

This month, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file.

Editing a Single File

Consider the simple situation where a developer needs to make a change
to one source file.  This case is obviously rather simple:

Why a Configuration Management (CM) department should be independent from Development, Test, and Production. When deciding where to organize an SCM team within a development organization it is helpful to keep in mind that the three most important characteristics of the SCM role are objectivity, skill set, and focus. This document will show that an independent SCM department is the only group with the right mix of these characteristics to successfully implement and support a full range of SCM services.

Cars and Clocks
In previous chapters I have mentioned the concept of a repository, but I haven't said much further about it. In this chapter, I want to provide a lot more detail. Please bear with me as I spend a little time talking about how an SCM tool works "under the hood." I am doing this because an SCM tool is more like a car than a clock.

You may now be tired of hearing me say it, but I will say it again:  Your repository contains every version of everything which has ever been checked in to the repository.  This is a Good Thing.  We sleep better at night because we know that our efforts are always additive, never subtractive.  Nothing is ever lost.  As the team regularly checks in more stuff, the complete historical record is preserved, just in case we ever need it. But this feature is also a Bad Thing.  It turns out that keeping absolutely everything isn't all that useful if you can't find anything later. 

I think everyone in our industry has heard at one time or another "It costs 3x more to fix software after deployment to production than it does fixing it right the first time." My question is; How do we prove that statement?

This month's article is about a little GNU Make Gotcha: an easy way to get tripped up by two pieces of GNU Make syntax that do similar things, yet one has a deceptive name. ifndef isn't really ifndef at all, it would better if it were called ifempty, while ?= does make its decision based on whether the variable is defined or not.

Software, we know, can be outsourced like sneakers, rubber balls, and helpdesks. That will put a damper on us in the career field of software configuration management. In the immortal words of the governor in Blazing Saddles, “We need to save our phony baloney jobs!” But what if we weren’t just managing software? What if we could apply the same principles to other products? Could we evolve into something more? Something bigger? Dare I say profitable?

Learn how to define and design an effective beta test with this hands-on guide to the best practices. Beta testing is an elusive aspect of product development. Often, it exists within varied organizations and produces mixed results. Through the integration of a dynamic Web-based information system and effective communication, beta testing can become a valuable part of the product development process.

Hey CM’ers!  Welcome to another fun filled, fact free edition of From the Trenches, the column where we get down in the mud to talk about the basics of Configuration Management and try to avoid any incoming shells.  This month we will talk about Software Configuration Management Plans (SCMP’s).  What are they?  Why do you need one?  How do you write one?  How can you delegate this task to someone else, anyone else?

What’s the ultimate goal of every software development project? Unless you just inherited a fat sum of dough from your late Uncle Milton, it’s probably to make money. The faster you can turn your project into a quality product in the marketplace, the more money you will make. Using a Software Configuration Management (SCM) tool will help you achieve that goal, and integrating that tool with other development tools can help get you there even faster.

Continuous integration is an automatic re-building of project code base that is triggered by new changes to ensure that new changes integrate well into the existing code base. Continuous integration gains popularity among software organizations for its ability to provide quick feedback on quality of new changes. This feedback is used to deliver timely fixes if the changes don’t integrate well and break the project code base.

Effectively planning and setting realistic expectations before you start your CM project can mean the difference between actual and perceived success and failure. Here are some great tips to help you sell the success of your project and avoid costly pitfalls.

Ineffective operating system level security can jeopardize your entire SCM operations and the hundreds of millions of dollars of software assets you are trying to control. It is important to match SCM to your company’s security model and use OS security to exercise control over application runtime environments, which CCM tools typically do not control. Here are some important guidelines for using operating system security to provide robust SCM for Windows and *NIX platforms.

A software build management server is an integral part of the Application Lifecycle Management (ALM) infrastructure. A typical ALM infrastructure consists of a version control system, a bug or an issue tracking system, and a build server. Software build processes such as Continuous Integration and daily builds are highly IO, memory and computationally intensive. Dedicating adequate resources to the build management server ensures efficient software development.

I’ve never been hired to convert a strongly process driven software shop into an Agile-based one. I usually bring Process into a shop where the de facto methods are very similar to what is described as Agile, but without the effectiveness that Agile development strives for. On the other hand, I never choke a software shop with Process either. I’m also well aware of how effective Agile-type development can be. Throughout this article, I will compare and contrast a process-based software production, “Process,” with Agile-based production, “Agile.” I am primarily concerned with the declaration in the Agile Manifesto that Agile favors “Individuals and Interactions over Processes and Tools.”

A number of issues that not only affected the SCM group, but the entire software development group arose while I was working at a company as the Director of Process Management. My primary focus was to develop a methodology (or set of methodologies) that would (1) reduce software build time and (2) make the overall software development lifecycle more cost-effective. The job at hand was to automate the company’s many manual business processes using a new application development system for automating e-business change.

For managers who are overseeing Java development teams, maintaining consistent coding standards and practices is a monumental challenge. Missed deadlines, reports of problems in the field and constant bug fixes are all symptoms of poor coding standards and practices. Fortunately, comprehensive code quality management applications are emerging that bring proven process standards to the development cycle, enabling managers to enforce code quality and track issues back to specific developers. By enforcing quality standards, problems can be proactively identified before applications are released, dramatically simplifying the development manager's job. This paper will examine the challenges faced by development managers and introduce how code quality management solutions that employ code Precision Team ManagementSM bring needed order to Java development teams.

The author provides a seven-step strategy for data center relocation/consolidation and identifies four specific pitfalls to avoid during such projects. He also addresses the critical impact of physical distance to a project, and how the distance can affect the end-users.

An organization's success in implementing and maintaining a process-oriented approach depends on two factors: process architecture and people management. This article focuses on ways to ensure the established processes are in tune with changing business needs.

Shunra provides a seven-step strategy for data center relocation and consolidation success. Four specific pitfalls to avoid during such projects are also identified. Lesser addresses the critical importance of considering the impact of physical distance to end users when planning these projects.

This paper provides a review of the projects that use business rules engine (BRE) implementation. The article emphasizes the importance of the rules taxonomy definition and concludes with a discussion about the estimate approach for this type of project.

With the unique processes and priorities of working in an Agile development environment come new opportunites and challenges for testers on the project. Tim Van Tongeren will examine communication tools and skills for software testers on an Agile development team. While the emphasis will be on Agile teams, the tools and skills are helpful for other development methodologies as well.

This Excel template provides a simple and effective method of tracking issues and bugs.

In today's world, customers expect to see software projects delivered in increasingly shorter cycles. The maximum time most IT customers seem willing to wait is about one year. In this fast-paced environment, the question becomes: just how much software can a typical IT shop create in twelve months? QSM's Doug Putnam logistically answers the question using production statistics from the QSM Industry database and the challenges he expects a team could face.

One of the challenges all software development organizations face is how to handle the defect-tracking process. Little thought is put into designing and implementing such a system. This white paper describes why a solid defect-tracking system is necessary.

White Paper: Overview of initial findings from a one year on-going survey conducted by PCI Global, an international Project Management training and consulting company.

The survey consists of fourteen questions rating all aspects of participating company's corporate project effectiveness. It has been administered to over 100 participants more than 80% of whom are project managers or team members–the groups who bear the brunt of their organizations' effectiveness. Readers will take and review each question revealing startling details about how effective their project management office really is.

PCI's initial findings suggest the greatest impact or predictor of project success is whether the senior management–knowingly or unknowingly–support, ignore or actually obstruct project progress. This may explain the high failure rates and costs reported elsewhere. The study also reports on project manager's complaints and recommendations to improve overall performance.

More and more companies are sending software development work offshore. While this practice allows companies to leverage an incredible talent pool at a lower cost, it poses significant challenges in managing projects. IT managers are struggling to perfect the process yet there is no proven way of managing offshore projects. In this article, Avi Verma presents a set of general guidelines for project and business managers to effectively manage offshore projects.

This White Paper considers the state of contemporary software development processes by analyzing their major problems and the core reasons for them. It explores how modern methods such as CMMI and Agile Development attempt to solve these problems and why they are failing to do so. The paper also provides an in-depth theoretical foundation for the necessity of a major paradigm shift in software development. A fundamentally new approach–Customer Oriented Software Development (COSD) is proposed.

This paper presented by SkyeyTech, Inc. explains how your company could benefit from utilizing BUGtrack for issue-tracking and project management needs.

Checklists play an important role in testing software. But these are the most under-used tools. Using checklists effectively can save time, cost, and make testing simpler. Checklists can be accommodated in traditional test methods and in the currently popular exploratory test methods.

White Paper: The DODAF standard defines a number of work products, some of which are identified as requirements for a system to be compliant, others are identified as supporting products that are recommended but not required. This paper discusses each product required by the DODAF and shows how standard UML views and semantics can be used to represent them. Clearly, the unifying nature of the UML meets the needs of the DODAF very well, now and into the future.

Automation is a great thing properly applied, but most companies lose sight of the value good manual testing brings. This paper uses a simple analogy to try and stress the importance of good basic skills and the tools to support them.

White Paper: Implementing and maintaining a CMMI compliant organization is key to the success of delivering on-time and quality products. Using CMMI provides the organization a framework for developing and maintaining good practices throughout the development and delivery of the product. The 5 levels of CMMI give organizations a roadmap and set of progressive goals to manage and improve their processes over time via the Process Areas. The benefits are clear, an ROI of 5:1. The challenge is in implementation. The need for an infrastructure to support and maintain this effort is key.

Zelger outlines what developers can do for test automators in order to succeed with GUI Test Automation. Learn how to introduce unique identifiers that enable test tools to easily identify controls and abandon coordinate- and/or index-based recording.

In the demanding, 'net-speed, pressurized world of software development, software professionals would do well to reflect on some truths about their customers, their industry, and themselves. Following a few tips will help you achieve what is ultimately the most important issue - satisfying the customer.

The fact that you test an application extensively does not itself render the application more stable. However, NOT testing an application increases the risk that the software may not comply with the requirements and won't necessarily provide the expected business value. Here is a method for approaching risk-based testing.

ROI is a widely used approach for measuring the value of a new and improved process or product technology. ROI is also used for measuring the economic value of popular approaches to software process improvement or SPI. This article explains the ROI of SPI, and introduces practical metrics and models for the ROI of SPI. Additionally, this article includes practical examples for estimating the ROI of Inspections, PSPsm, TSPsm, SW-CMM®, ISO 9001, and CMMI®.

Rigorous performance testing and optimization is a critical factor in the successful delivery of any business application. Yet frequently the performance of deployed applications doesn't live up to business requirements or end-user expectations. Shunra Software Ltd. describes their approach.

This article details the importance of requirements and reviewing requirements. Including what testers should look for in acceptable requirements for the development of test cases.

This software quality assurance (SQA) Guidelines template provides a comprehensive, high-level definition of the activities and procedures used to perform quality assurance in a software development and support organization.

Customer choice is the virtue of product quality that can make or break the success and survival of every business enterprise. Business objectives are not defined by just the bottom-line, as many would have us believe. They are based on creating and retaining satisfied customers by providing products and services that meet and exceed customer needs. In all these dynamics, QUALITY is the primary protagonist, the vital ingredient, and differentiator. This article examines quality assurance as an advocate for customers during product development.

In this case study from a major retailer, Antonet Bekker describes how to evaluate a system's usability in step-by-step approach. Often, recommended improvements to the software's usability design before (or after) the software goes live will result in dramatic increases in efficiency and effectiveness.

William Ginn shares his success at strengthening his QA team in a chaotic and changing development environment. Use Ginn's experiences to help build and maintain a strong QA/testing team that is valued by upper management while successfully competing for limited IT budgets. Learn to implement new, agile development methodologies while continuing to create and demonstrate value.

This article discusses how to use bug taxonomies to help generate better tests. The author explains that a test team's goal should be to create a useful taxonomy that can be used as a framework to brainstorm for possible risks to the application.

According to the Sky I.T. Group, in today's latest web development environments, there are over 7000 possible configurations of Operating Systems, Browsers, Screen Resolutions, and other unique characteristics.
How to produce all these different environments? The traditional way is to build a big test lab equipped with various hardware and software configurations supported. This approach has obvious limitations. Read on as the author explains more on this subject.

Organizations that don't expect and encourage about 20 percent of their projects to be stopped may either be wasting resources or implementing only the safest bets. Denying reality or playing it safe may be the riskiest strategy of all according to industry authority David Gelperin.

This Sarbanes-Oxley Compliance Matrix is an Excel template that includes guidance on how technology and software applications can meet the SOX financial criteria.

Most of the books and articles on testing are written with the view of a new project or a product. Due to a large number of mergers and acquisitions, IT departments are seldom afforded the luxury of purchasing new products. Managers must get the job done with the current systems already owned by their companies. This article looks into the problems faced by the QA team and explores the possible solutions to get a quality product out of the door.

As the layer between the business sponsor and the end user, and as the one who is ultimately responsible for the success of a project, project managers occupy a challenging role. Often, we find ourselves playing the role of leader, diplomat, counselor, and dare I say it, salesperson. To achieve success, it is crucial to build a solid foundation of teamwork and respect among those involved in the project. In this article, Patrick Graves explains how this can be accomplished.

How does your company measure the value of testing their Web applications? Do they only notice when an application fails or when a business partner or end user calls with a complaint? What if tests could provide management and marketing with information to directly affect the bottom line? QA would then become a different kind of hero. This article offers ways you can promote the value of testing and QA in your organization.

In this presentation, Jim Hart explains how software testing relates to the CMM and how you can measure the maturity of your testing processes.

Software benefits tremendously from code review. Establishing an effective review process requires management commitment and follow-through, but it is well worth the effort. In this article, Ed Hartnett suggests some best practices to follow in your code review process. This article originally appeared in the Tech Support section of Volume 3, Issue 3 of Projects@Work.

Automated testing is recognized as a cost-efficient way to increase application reliability, while reducing the time and cost of software quality programs. Some of the common reasons for automating are reducing testing time, reducing testing costs, replicating testing across different platforms, repeatability and control, and application coverage and results reporting. This article helps beginners adopt the automated testing approach. An example of simple architecture adopted in a client server project is also included.

The case for automating the Software Testing Process has been made repeatedly and convincingly by numerous testing professionals. Most people involved in the testing of software will agree that the automation of the testing process is not only desirable, but in fact is a necessity given the demands of the current market. The purpose of this document is to provide the reader with a clear understanding of what is actually required to successfully implement cost-effective automated testing using automated test tools.

Web site quality is critical to success. Organizational Web teams are facing demanding environments characterized by budget cutbacks and sprawling Web sites created by legions of content authors. In this article, Al Caughey discusses the advantages of using an automated Web quality management solution to improve coverage, reliability, and return on investment.

When an error is found in an application during development, the automated error prevention method helps you correlate that error to a specific point in the development process, and allows you to modify your processes to remove it, and more important, to prevent it from happening again. Preventing errors, rather than chasing them, dramatically improves software reliability. This way, you can stay competitive and not risk your valuable reputation on unforeseen bugs.

Testing is a compulsory step in the software development process. The Classification Tree Method offers a systematic procedure to create test case specifications based on problem definition.

Web applications are based on client-server, request-response mechanisms. Performance of any moderate- to high-functional Web application is directly proportional to the architectural decisions and the technologies chosen to support it. Performance also depends on the architectural awareness of a programmer and his ability to address it from the inception phase of any Web-based application. This paper also discusses various ways to enhance the performance of Web-based applications.

Although nobody denies the need for dynamic software testing, until now there has been virtually no tool support for this important task in the software development process. Therefore, dynamic software testing is mostly performed interactively. Tessy is a commercially available tool that facilitates the automatic dynamic testing of software for embedded systems.

Are too many bugs making it into your software releases? Are quality issues causing project delays, and escalating development costs?

Learn how you can improve software quality, and save significant costs by finding defects earlier in the development process. Impact Analysis allows developers to better comprehend complex software systems, and assess the impact of changes to code before they are implemented.

If you are unable to answer these questions for any of your software projects, read this white paper and discover why Impact Analysis should be part of your SCM solution.

STATE (Software Tool for Automated Test Environment) is a testing framework that can be used for testing any protocol/stack implementation. This paper explains STATE features in detail with the objective of helping reader understand what STATE is and how it can help to simplify and automate the testing process.

Automated testing is essential for performing thorough and fast testing. Given the need to accelerate software development and reduce the time to market in the fast changing business environment, automated testing could prove to be the vital link to success for many companies.

Performance in a Web application is of utmost importance. This paper discusses the various types of testing that should be performed while measuring the performance of a Web application, the different workload models, and the ways of measuring response times using automated tools. A good performance tool aids the testing process and can be the smartest way of measuring performance in a project. End-to-end performance is the last stage of the project in a typical Web development iteration cycle. This paper also talks about some crucial design factors that improve the performance of a system.

In the past few decades, three "big hitters" have stepped up to the plate of building better software-formal methods, tools, and process improvement initiatives. Unfortunately, they have all struck out, according to James Whittaker in this week's column. Read on for his critique of these supposed cure-alls and for his call for a new kind of player on the field.

KLCI Research Group presents the results from the Software Risk Management Study performed in the second quarter of 2001 with more than 260 participants worldwide.

This paper describes inspections, including advantages of inspections, the people involved, and roles and responsiblities of the team. It includes templates for a preparation log, defect log, planning, and followup.

In software testing, one has to go beyond the boundaries to explore the existence of not yet discovered errors. This article will discuss testing dos and don'ts and give a few tips for successful testing.

As Web services increase in complexity and connectivity, security is growing as a major concern. Many security breaches have been the result of poorly tested software that allows unexpected inputs to pass and weaken security measures. Such inputs can create conditions in which intruders can obtain access to parts of the system that would otherwise be secure. One effective way for development teams to prevent unexpected inputs is to perform thorough white-box testing at the unit level. Unlike specification testing (which tests that code behaves as it was intended), white-box testing checks for the conditions and inputs that are not expected, thereby enabling developers to more thoroughly test for what they cannot foresee. By performing such testing at the unit level, developers can quickly and easily identify and correct any weaknesses before security breaches have the opportunity to occur.

This article describes how to write quality software requirements using case study examples to support the contentions presented. The study is based on observations (and documentation) made of a successful software development project and the process used to produce the project software requirements. The article also exposes the difference in quality as it applies to the conceptual software requirement and quality of the SRS document.

This paper provides an overview, in a nutshell, of the concept of Traceability Matrix, the importance of it, the areas where it can be used and the means of creating it.

 This paper shows you how to effectively place your focus not on the action or process to be completed, but rather on the object type that's to be manipulated. This redirected focus lets you avoid the pitfalls and resource requirements encountered when you move to test another application. Here is a demonstration of how this modified approach can be integrated into the manual test case creation as a way to tremendously improve efficiency.

This paper provides senior IT managers and executives in financial organizations with insights into implementing quality and best practice initiatives, particularly when coping with the aftermath of mergers or acquisitions. It will help managers and executives to: understand some common issues created when IT-dependent organizations merge; effectively assess the role of large-scale quality and benchmarking initiatives, such as Six Sigma, TQM, and CMM in the changing organization; and consider some simple ways of implementing quality initiatives at a pragmatic level, which may provide a faster return on investment.

Testing science states that it is impossible to achieve 100 percent test coverage in testing software. Based on the risks in a project, the desired amount of test coverage is arrived at and established. It is impossible to uncover all the defects early in the software development life cycle. For example, performance defects remain uncovered until the software is integrated and moved to the performance testing lab. This article puts forth a metric that depicts the status of defect migration.

This paper talks about the best tool for designing the star as well as the snowflake schemas. It discusses how to analyze the business and develop the requirements to the implementation of a data warehouse.

This paper describes the adaptation of Functional Reliability to the rapid application development environment. Every third week since January 2000 we have cut, tested and evaluated for release a new version of our software products. Solutions to anticipated and unanticipated challenges involved in the modeling of reliability for this process are described with an emphasis on evaluation of risk pre-release and how field results are fed back into release decision process.

Distributed development teams are becoming the norm for today's software projects. In lieu of close physical interaction, distributed teams are faced with the challenge of keeping software projects on track and keeping remote developers involved. This article provides some suggestions for keeping distributed software teams in touch and on target.

Automated Software Production and Test (ASaP) is a coherent approach to improve software development by full automation. An engineer delivers system information and gets an automatically generated, correct system and textual and graphical reports on the system's properties without any human intervention after some "ten minutes." ASaP generates an equivalent of some man-years within one hour on a PC or workstation free of bugs.

The project plan is clear and the specifications are detailed. So why is the final product so different from what you expected? In this week's column, Nicole Auger brings a product manager's perspective on how features get changed or added during the development process. And she gives tips on how to get what you ordered, instead of a substitute.

While the process of estimating testing in the software industry may be different for each project, all share the common thread of Requirements. This article has attempted to introduce guidelines to simplify this process.

In this column, David Gelperin presents a problem familiar to many of us—what is the best way to record requirements? Given the limitations of static templates, how can we best manage high-volume, multidimentional requirements information? Read on and then share your experiences.

The testing of software is critical to the attainment of software quality. Reliable, meaningful
test results can only be obtained by a test facility operating within a properly structured
management system, using validated tests run by staff who understand the limitations of the
tests. Test laboratory competency can be confirmed through independent, third party
accreditation of the laboratory against the requirements of ISO/IEC 17025 General
requirements for the competence of testing and calibration laboratories. Such accreditation
supports software quality life cycle initiatives.

This article provides the background for understanding and applying the measurement process described in ISO/IEC 15939.

This case study uses the example of an ATM machine to serve as a tutorial for writing test cases for functional integration testing.

This article provides a guide for hiring a Software Quality Assurance (SQA) specialist. It provides tips on what questions to ask and what problems to avoid in order to hire the right person.

In this paper, we'll discuss how testing can be expanded to cover all aspects of Total Product Readiness (TPR). You'll be able to verify that each of these vital components has been properly planned and prepared for during the product development cycle. 

In a previous article, we discussed about the use of Rational Purify to detect the memory leaks in one of  the applications that was developed using J2EE technology. We have also discussed briefly about the analysis procedure and given some suggestions to avoid  memory leaks.  In this paper (on the basis of the feedback received in my teaching session on Purify), we are discussing a hands-on exercise (MemoryLeaksAfter.java) to give a close insight to understand memory leaks and their prevention. The program was tested using Purify and the results obtained from such a study are discussed here.

Quality assurance (QA) professionals often are squeezed into the Web application development process too late in the game, and thus have no chance for success. Common QA frustrations include lack of planning and processes, unrealistic schedules, and lean staffing and financial resources allotted for the QA and testing phase of a project. RadView's Michal Blumenstyk offers guidelines to ensure QA can deliver what it promised.

Treating testing as a black box at the end of the project schedule invites failure. Testing and test preparation need to be open, managed, and manageable processes that everyone on the project team can understand and work with. Having insight into all testing requirements and desired outcomes is an absolute must for effectively managing a successful testing effort.

This matrix can help you estimate test effort. It's based on use cases and test point analysis and is highly customizable.

Extreme Programming (XP) was created in response to problem domains whose requirements change. Spreadsheet development is often done in conditions of intense time pressure, for example in merger and acquisition analysis. The spreadsheet development itself is often used to develop an understanding of what is being modelled, and therefore change is constant.

Based on the Vmodel, this paper describes a model that shows how the tasks for testing relate to the tasks in the development model. This testing model-the W-model-further clarifies the priority of the tasks and the dependence between the development and testing activities.

This paper focuses on establishing test automation as a service in the software development organization at the outset, with the importance being given especially to the testing group. Test automation should direct its efforts to increase the efficiency and effectiveness of the manual testing process by providing 'Quality' Test Automation services. Test Automation should always aim at supplementing the manual testing to quickly assess the quality of the application under test through the execution of quality test automation suites. The building blocks of test automation services are discussed thoroughly to successfully finish test automation projects.

This article develops a Software Configuration Management (SCM) Reference Model. This model is intended to be a concise and practical guide which brings together in an outline fashion the framework and methodology necessary for planning, customizing, and implementing an SCM approach, independent of specific SCM tool technologies or system platforms.

This paper explores the relationship between SCM and the modern development models, provides an explanation of how to provide SCM in a quick, concise way, and describes how to adapt the "Just Enough SCM" philosophy to the most demanding standard.

Estimation is not an easy task. Estimating testing projects is harder. If there are no tools or methodology to support it, the estimation process is a nightmare for those responsible for it. This essay describes a real experience in the estimation process. It also shows some rules, metrics, tools, and tips that guide a testing team through the estimation process.

The software industry historically has been plagued with an inability to release products that are adequately tested. Examples of poor quality in the software consumer market abound. From applications that can only be considered fully functional after a half-dozen "upgrades," to the frequent reports of damaging software viruses that reflect poorly on software security and stability, the software industry is consistently indicted for quality lapses. Put bluntly, much of the software in the consumer market isn't worth the cost of shrink-wrapping. This article serves as a rallying cry to bridge the gap between software quality efforts and other industry quality efforts.

This application brief describes how the unique and powerful technologies employed in the WebAvalanche and WebReflector will help IT service providers attain the highest levels of application-level quality of service from their network infrastructure.

This Software Test Script template designed to keep track of automation status and revision history. It includes places to record issues, pre-conditions, and test steps.

Testing applications on Pocket PCs requires a special strategy and plan. It's different from testing normal client/server or Web-based application. Testing applications for Pocket PCs is like a mixture of strategies applied for testing client/server and Web-based applications. The test strategies applied for testing client/server applications like compatibility on different platforms, different hardware and software considerations, user interface and the strategies adopted for testing web applications like compatibility on different browsers (if it's a Web application for Pocket PC or PDA), security (authentication, authorization, data confidentiality) should be taken into consideration.

Apart from the above, there are few more issues that we need to address while testing applications for Pocket PCs.

(MKS Product Whitepaper) There are unique challenges associated with enabling teams in multiple geographic locations to collaborate on the same software projects. A common myth is that replication is the answer. To this end, MKS introduces a new and innovative solution called the Federated Server Architecture (FSA). The FSA, developed by MKS, uses advanced and reliable caching technology while building on the widespread advancements in network availability and reliability. The result is a solution that has numerous advantages over the outdated replication paradigm, including lower total cost of ownership, reduced administrative burden, and access to real-time project information. Read this paper to learn more about the FSA and how MKS supports multi-site development.

In this article, Adam Kolawa provides a quick overview of RAD, XP, and PSP, covers the main pros and cons of each process, then explores how these processes might be combined in a complementary manner to suit different development needs.

This paper describes how iterative software development process has been adopted in RAFAEL, based on the Unified Software Development Process (USDP) introduced by Rational Inc. The paper identifies the core differences between iterative and waterfall software development, addresses the possible difficulties in applying the iterative process and details the elements of an iterative software development process tailored to RAFAEL.

Manual software testing can never catch all errors–so can automation help? David Norfolk looks at the pros and cons of automated testing and offers advice–and warnings–on its use.

We can all learn to be better estimators, and our projects will be safer and stronger for the effort. In Tom DeMarco's book Controlling Software Projects, he presents a simple method for tracking and scoring the accuracy of your estimates. Here, Tim Lister walks through the process.

Writing isn't easy--let me just make that perfectly clear. Anyone who tells you that writing is easy is either lying to you or doesn't understand what quality writing entails. Writing requires careful thought, a great deal of planning, constant review of your work-in-progress, and a great deal of skill, which can only be gained through experience and practice. Sounds a lot like a description of software testing, doesn't it? The truth is that there are a number of similarities between quality writing and quality software testing, and skills in one discipline can help you a great deal in the other, both directly and indirectly. While written documents may or may not be required within your test team, the process of writing can be extremely beneficial in itself.

Development is treated as being different from maintenance, somehow more special and elite. Maintenance programmers, however, have solved problems that developers tend to keep reinventing.

Scapa Technologies has developed a unique n-Tier Resonance technology that resolves the synchronization problems of stress testing in tiered architectures like Citrix ICA. Stress that is introduced at one tier in the architecture is made to resonate accurately through other tiers of the architecture so that it becomes possible for server loading patterns and client-end timings to reflect the effects of communications latency. The resonance is achieved by binding together tiers of the architecture using low-level synchronization logic.

Use this template to write a softwre test plan with the required test cases. I recommend using this template for smaller projects that do not require a full-blown test plan plan.

As with many new concepts, Rapid Application Development, or RAD, can seem to take on qualities of magic. One can sit with users and construct an application in front of their eyes to directly meet their needs. Seems too good to be true, and it is. Building good software applications requires discipline and tedious hard work. Visual programming tools are making software development efforts less tedious, but they are not a substitute for the hard work and discipline required to build high quality software.

Branch coverage is an important measure of the thoroughness of testing. One can get coverage tools for mainstream languages (C, Ada) on mainstream platforms (Solaris, UNIX), but not for unusual languages (JavaScript) or running on nonstandard platforms (C in embedded systems). This paper shows how program transformation systems can install test probes in software systems easily. This means test coverage is possible for all kinds of software in all kinds of execution environments.

When unnecessary information is entered into bug-tracking systems, they are not as effective as they could be. In this article, Adam Kolawa outlines what type of information should be entered into a bug-tracking system during development and after code freeze, and how to use the information when designing future product versions.

This paper talks about testing for reliability of server software, and highlights the challenges in planning, automation, execution, collection, and interpretation of the data for determining reliability as well as some practical challenges/difficulties faced. It also talks about the relationship of reliability testing to other areas of testing such as performance and functionality.

Few development projects deliver as promised - exceeding budget, missing objectives or failing to satisfy expectations. A consistent feature is that users frequently do not understand the system being developed for them. Too often, the result is dissatisfaction and costly rework.

Applications prototyping offers the best chance of avoiding such scenarios. This white paper will look at a solution for developing an effective prototype that users can actually work with during development.

Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. Karl Wiegers gives some tips on decision making that can help you avoid this outcome. Karl also shows how to use decision points to keep a good project moving along.

In an attempt to do more with less, organizations want to test their software adequately, but as quickly as possible. Faced with this reality, software managers and developers have little choice but to introduce automated testing to their projects....The introduction of automated test tools helps to replace archaic and mundane manual test processes with a more professional and repeatable automated test environment, that promotes test engineer retention and improves test engineer morale.

Making the decision to standardize on a single SCM and change management solution across the enterprise, along with common processes and development methodologies, has important benefits for the organization as a whole, but also for individual software development teams within the organization. This white paper will make the case for standardization and then provide recommended solutions for minimizing the pain that comes with changing software development tools and associated processes midstream.

Model-based testing offers advantages like automating test generation and providing a basis for statistically estimating product quality. These perks can be enjoyed provided the right models are used, the proper resources acquired, and adequate training undergone. Model-based testing is not without difficulties, and knowing what they are and whether they can be avoided and how is k

We can debate the pros and cons of one development process over another until we're blue in the face, but the simple fact is that we will never declare a true winner. There simply is no silver bullet development process that will help every development team deliver every product on time and on budget. This article provides a brief overview of three development processes and when they are most appropriate.

"That's just the way it is." Does that sound familiar? It's the answer we often get when asking the reason behind the way things are done on a project. How much better it would be if everyone on a project knew the "whys"-the purpose of the project, the reason behind the delivery schedule, the significance of the project to the organization, etc. This article describes the benefits of an environment in which people know why, and it explains how to create and maintain that environment.

This document identifies guidelines that review high-integrity software requirements documents in nuclear power plants. The topic areas are conformance with the SRP, accuracy, functionality, reliability, robustness, maintainability, security, timing, and human-computer interaction. A checklist for the requirements and their ordering for a Software Requirements Specification in accordance with IEEE Std-830 is discussed.

This article discusses the road blocks I have encountered while attempting to acquire consulting engagements for myself and others. They are a result of the management misconception that all you have to do to automate software testing is to write test scripts. The immediate effect being that QA and testing functions are being staffed with test script coders at the expense of test designers. It all reminds me of a cartoon from the golden age of computer programming where the manager says to the programmer, "You start coding and I'll go find out what the system is supposed to do." The software testing corollary would be "you start testing and I'll go find out what we are supposed to test."

QA automated test development is a software development process although it is seldom treated that way. Following software development practices can make the difference between the success and failure of an automated testing project. One of the most important aspects of any automated test design is the ability to share and reuse code. A well thought out design promotes code reuse, speeds development, and reduces the maintenance of automated tests. Most software tests are made up of combinations of simpler operations. This paper introduces the Sequencer design that facilitates the creation and execution of reusable operations. The idea behind the Sequencer is to carve the product under test into sets of functional operations. A test case data file describes the operations to be executed including their order and required data. The Sequencer's test driver executes the test by loading the test case and sequencing the operations.

If you establish an appropriate infrastructure, you can perform client-side testing on a servlet immediately after you compile it and perform unit testing. Of course, testing early doesn't eliminate the need for later application-wide testing. However, it does improve the overall efficiency of your development process and make the later phases of testing decidedly less painful.

In the busy world of quality assurance and testing, we often as individual testers/quality assurance professionals dig in and do the daily work we need to do and sometimes leave the overall quality measures to those in management positions. As individuals we need to realize that each of us makes an impact on quality, whether we are proactively and consciously doing so or not.

Agile development increases business value for the customer, with the customer controlling the variables at each iteration. Ken Schwaber, co-creator of the Scrum agile approach, explains the basic notion behind agile development. A number of useful links appear at the end of the article.

This article gives a solution for workspace management by implementing a simple process.

Load testing is evolving as a discipline and it has discovered most of its business in the Internet economy. This paper examines various types of load testing and provides a detailed discussion on the load testing process. All load testing tools simulate realistic volumes of users to measure, define, validate, and maintain optimal application performance. There are many tools available on the market that can help in load testing, but this paper presents a brief overview of Web Application Stress Tool (WAST) that can serve the purpose.

This paper is based on a recent experience implementing and testing a large new software capability in a maintenance organization which had not dealt with a large change in some time. The capability was called GPC Payload Command Filter (GPCF).

This paper is a guide on how to create Table Driven Test automation with off-the-shelf utilities and commercially available GUI testing tools. It demonstrates the benefits of using a table driven approach and presents various engines, utilities and documents that enhance or support this third generation testing architecture, which I call Enterprise Test Engine Suite Technology (E-TEST).

Creating effective management control instead of bureaucratic procedural "hoops" saves time and cuts development costs. But well-defined procedures are necessary to keep documentation in sync with the rest of the pieces of the project. In this article, Gill discusses specific documentation-process elements that will help improve the overall development lifecycle.

The earth is flat. Mankind will never fly. Reasonable people believed these "facts" for thousands of years, but advances in knowledge and technology proved them wrong. Does the software testing industry have any such "facts"? In this paper, I will explore common testing beliefs. Using experiences from SAS, I will attempt to confirm or refute these pieces of conventional wisdom.

The paper describes how an organization plans and executes training to ensure the best possible use of resources to meet organizational objectives. There is a discussion of common problems, and measures to avoid or correct those problems. While the focus of the paper is achieving compliance with the CMM Training KPA, its content is relevant to any organization engaged in training technical personnel.

Software measurement specialists are part of a long tradition of economic theorists, even if many don't recognize their ancestors. Notions of efficiency and how to model economic change are implicit in measurement strategies pursued. Software measurement is difficult because it requires a sophisticated understanding of how innovation can be fostered. Economic theorists have known for a long time that the short-run models do not capture the innovation that drives growth. Dr. Fado is a professional now involved in a software development metrics program, interested in making software measurement work for business benefit.

Testing smarter means delivering quality applications. However, some development organizations are not focused on planning and managing the testing process within the application life cycle. Testing is often considered a lower priority relative to development when, in fact, designing a comprehensive testing strategy can be as challenging as designing the application.


In today's market, quality is becoming a competitive differentiator. If companies want to be competitive, application testing must be a high priority.

The biggest obstacle to implementing a successful software measurement program is getting the software professionals, the ones in the trenches designing, coding, documenting and testing the software, to measure their work.

In this column, Bob Glass returns to a topic that stimulated a lot of discussion on this Web site in his previous column--the definition of software quality. Here, he responds to your comments, which totaled more than double the usual number. Bob stands his ground (with some clarifications) on what quality is…and isn't.

Perforce is recognized as the fast, low-overhead, high-throughput solution in software configuration management (SCM). What's not as obvious is how Perforce solves the problem of Web content management (WCM). Perforce is used in a wide range of WCM applications by: organizations using an intranet for internal documentation; companies whose product is Web content, not software; and individuals, companies, and organizations with external Web sites. This paper surveys the Perforce deployment models currently in use for web content management, and identifies the features that make Perforce a suitable WCM solution.

This paper explains about testing the object-oriented classes at unit level for their functionality. A new approach has been developed to test the functionality of the object-oriented classes at unit level.

Open source development projects typically include a testing phase, just like their commercial counterparts. But how do open source projects manage the testing process? What tools and resources do these projects use? This article discusses the ways that open source projects accomplish testing goals, and how open source testing compares to testing in a commercial project environment.

Driving usability improvement in a company with over 100 different remotely-located software development organizations, each using independent development processes, presents specific Software Quality challenges. This paper describes the usability acceptance testing and usability risk assessment approaches that one organization instituted within this complex development environment, from the ground up. 

Packaged applications are being widely adopted at mid- and large-size companies to automate both internal and business-to-business processes. E-Business/ERP implementations are usually part of a broader enterprise computing effort involving the integration of Web, server, and host-based applications.

The instant worldwide audience of a Web site make its quality and reliability crucial factors in its success. Correspondingly, the nature of the WWW and Web sites pose unique software testing challenges. Webmasters, WWW applications developers, and WebSite quality assurance managers need tools and methods that meet their specific needs. Mechanized testing via special purpose WWW testing software offers the potential to meet these challenges. Our technical approach, based on existing WWW browsers, offers a clear solution to most of the technical needs for assuring Web site quality.

"It is inevitable that sooner or later, someone higher up the food chain is going to ask you for documentation metrics." In this article, Donald Le Vie distinguishes between "mechanical metrics" that don't really measure your productivity, and "quality metrics," which are more difficult to use, but much more accurate. Le Vie provides excellent examples of these, and analyzes the value of various types of metrics.

This article reprinted with permission from INTERCOM, the magazine of the Society for Technical Communication (STC).

In this column, Bob Glass skewers one of the "old wives' tales" of the software field, the theory-based prediction that software reuse will lead to unbounded improvements in both development productivity and software quality. "It ain't so," he says here. But he certainly wishes that it were.

It may sound counterintuitive at first, but making tighter deadlines may improve software quality. When deadlines are strictly adhered to, the panic and rush as the deadline approaches can undermine quality of product. Heller discusses how a looser, but earlier deadline can encourage a healthier environment, and higher quality.

An important component of any security system, its multi-layered access and encryption permissions provides a powerful combination, when configured properly. However, time and time again I find myself in front of a Windows 2000 Server, where a failed permissions configuration succeeded in creating a tangled mesh, denying access to everyone. At this point, without a documented roadmap, it becomes difficult to unravel the conflicts, but I hope to shed some light on what to do and avoid form personal experience.

When it comes to measurement, the IT industry acts strangely. Even when it recognizes the merits of software measurement, the expectations for it are often unrealistic. Software practitioners want a silver-bullet metric that can answer any development question and do it to several-decimal-point accuracy. This article addresses the mistaken notion of measurement or a particular metric being a silver bullet - a notion that left untapped can impede your organization from ever getting started with measurement.

This article is aimed at providing team-based development for a small organization. It provides a solution to effectively utilize the resources present in small organizations and suggestions to overcome the shortcomings in terms of sophistication of tools and processes. It explains how small organizations can come up with a better and more efficient configuration management system by taking advantage of the current situations and resources. This article also explains how by effective communication and simple process definitions and implementations the magic term 'managed and controlled' can be achieved. This is a more simplistic approach towards Software Configuration Management.

As software technologies continue to grow in power and complexity and microprocessors continue to shrink, we are witnessing the rapid expansion of software into virtually all areas of our business and private lives. Today, it is found in cars, traffic lights, household appliances, communications and transportation systems, hospitals, airplanes, medical devices, next-generation payment cards, business supply chains, and enterprise management systems. Software is truly becoming ubiquitous. This article illustrates the consequences of software failure, the dynamic process of risk analysis, and the importance of the right business decision.

The rapid development of applications nowadays does not always leave a project time to perform lengthy assessment of requirements and time to test; as in most cases, time is of the essence. Identifying a simple process for gathering and assessing Requirements makes the testing of applications easier and lessens the risk of delivering inadequately tested software. This paper provides the steps necessary to implement the process.

Can measurement be the system development savior of the 21st century, or is it a passing fad? The truth lies somewhere in between. The secrets of highly successful measurement programs extend well beyond the technical correctness of the chosen metrics and collecting of data. This article explores these secrets and identifies characteristics critical to measurement program success. The secrets of highly successful measurement programs extend well beyond the technical correctness of the chosen metrics and collecting of data. This article explores these secrets and identifies characteristics critical to measurement program success.

Most of the Test Managers say, "Testing without test plans is a crime." The testers should know what is being built and should analyze the way to proceed. He/she will have to prepare the test plans based upon that to proceed with testing the application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who don't have much idea about Exploratory Testing, a small intro is given here.

This paper presents data on the effectiveness of software fault insertion, discusses the advantages and risks of fault insertion, provides tips on gaining cultural acceptance for fault insertion and suggests high payback areas for fault insertion which have proven themselves over multiple products. In a typical software development cycle, defect detection starts to trail off once the mainline code stabilizes. With software fault insertion, it was found that the defect detection rate does not level off and the hardest task becomes not one of finding defects but one of prioritizing the stream of defects.

The Mocrosoft Windows team has transitioned from having no standards to having a strict set of guidelines to follow when writing new automated tests.

Have you ever run an installation program that wreaked more havoc than the installed application was worth? We often talk about user headaches from faulty software, but sometimes the pain begins with the installation process itself. Just for fun, here's a humorist's fictional account of a nightmare installation he (barely) endured.

The presentation will explore and illustrate: the evidence of a problem establishing software measurement programs; the history of measurement, including the emergence and description of the Pantometric paradigm; the importance of different modeling Software Engineering Dynamics--systemic, empirical & metaphorical. Some techniques for modeling Software Engineering Dynamics. A new focus for software measurement.

Measuring the progress of a software project requires a metric of the value the project creates. Progress implies a plan against which to measure. The concept of earned value provides a clear metric of project progress relative to a plan. For this purpose, the usual cost metrics for earned value are less interesting in a software project than other measures of value. In particular, function points provide a measure of value that earned value metrics can easily use to compare what you've created to what you plan to create.

This paper outlines how Efficient Defect Analyzer has been successfully applied, potential pitfalls, and some possible future directions.

The Systems Storage Development - Systems Storage Division (SSD-SSD) of IBM has used a method for process change that has seen some quantifiable results toward product quality, even though the program is still in its infancy. This methodology, called Orthogonal Defect Classification, results in defect reduction and preventive actions that are quantifiable. 

Lots of things in the software field have been labeled as "breakthroughs." Invariably, they are not! Inspections, on the other hand, have never been labeled as breakthroughs. But the reality is, they nearly are! Here are some surprising thoughts on what inspections are, and how to perform them effectively.

This is a template for a simpified unit or integration test plan.

This checklist summarizes the steps for securing an investment in testing. The process is neither sequential, nor automatic. That's part of the point. This is essentially a mechanism for securing investment (resources and commitment) to produce some value for the organization.

Extreme Programming (XP) is all the buzz these days. Business' motivation is to decrease time-to-market, maximizing revenue opportunities. Without quality practices that keep pace, new releases deliver defects just as quickly! Quality testing also often fails to provide complete identification of the launch risk, making enterprises vulnerable upon launch. Often there's no time to test, and automation doesn't seem to shorten time-to-market. Jim explains how he escaped this dilemma at Egreetings.com, a top 50 website.

You have an approved project that is about to begin - the project team is in place, the product owner has been identified - the stakeholders are eagerly waiting to see results of this agile approach that they have all heard good things about ...

Here's your dilemma ... the stakeholders are expecting to see tangible progress at the end of the first iteration in two or three weeks - having been through presentations of Agile processes. But you know that it's really not feasible to deliver anything remotely useful in that short a period. Agile processes warrant early delivery of business value, stressing on working code. Release planning and iteration planning are all based around user stories completed to the extent of being ready to deploy. But the reality is often different.

So how did they test the capacity of the computer dinosaurs of yore? Randy Hayes was there, and he gives us a taste of what it was like. Even with automation, a simplistic approach can be very tedious. Randy also demonstrates that simple automated load tests don't necessarily test what you think they do, and they don't necessarily give accurate results until you've taken steps to ensure that they exercise the system the way real users would.

Effective requirements management includes selective requirements measurement. You can make sure your project is staying on track by counting the number of requirements you plan to implement and tracking their status during construction. You can stay focused on meeting delivery targets by monitoring requirements change requests. You can even estimate future projects better by tracking the time you spend on requirements engineering and correlating requirements definitions with development effort. Or alternatively, you could just ship the product when it "feels" done. It's your choice.

This paper provides an analysis of challenges that engineering and human resources managers face when attempting to recruit new staff. Successful staffing of a software engineering organization in an intensely competitive market is described in terms of the key elements of the staffing process and proven strategies that help to stay ahead of the competition.

In this e-Talk Radio show, Ms. Dekkers and her guest, Taz Daughtrey, editor of the Software Quality Professional journal, talk about urban legends surrounding software. They also address the topic of professional certification for software developers and testers.

In this show that aired one week after the U.S. Presidential election in November 2000, Ms. Dekkers and Mr. Pressman talk about system failure and the importance of ergonomics in designing human interfaces.

About the Show: Ms. Dekkers, Mr. Magee, and Mr. Voldner give an overview of ISO standards and talk about how to implement standards in your company, regardless of its size.

Computer-related business, organizations, and institutions have universally recognized the need for visibility on the World Wide Web. But what used to be a simple tool for educational institutions to share information has turned into a new venue for marketing, selling, and gathering information. This effort requires a design and deployment plan that is fundamentally different from all other software products or projects ever conceived because of the extremely wide accessibility and expectations from target audiences. This means that software organizations face a paradigm shift in order to adequately address the radically new needs represented in the World Wild Web.

Critical Chain Project management uses statistical process control to more clearly define the relationships between tasks and the project end date by using buffers to represent process variation in project tasks. This paper shows how integrating effective statistical process control with the use of function points and standard processes can dramatically improve your ability to plan and control projects. Using examples based on real-life experience, it provides a simple method for controlling variation and risk.

Phase Containment Effectiveness (PCE) measures the ability of software development phases to detect faults. A weakness of this measure is that it determines how effective the phase was. This paper presents a fault prediction model that uses the PCE and related process measures to statistically predict the number of Faults, Errors, and Defects.

About the Show: Ms. Dekkers and Ms. Winward talk about improving relationships within teams through handwriting analysis.

Why do some teams "catch fire" and excel, while others never seem to gel? Ms. Dekkers and Mr. Lister talk about this, as well as other topics from Mr. Lister's book, PeopleWare.

The quality of the software you produce, the productivity of the people who produce the software, and the cost to produce that software is directly influenced by the quality of the process that's used to develop that software.

In this discussion, Dr. Alan Davis advises software developers to "make sure you write your requirements down, make sure you learn what your customer's needs are, and make sure you pick the right set of requirements that enable you to actually meet your schedules and your budgets."

Traditional intuitive requirements decomposition fails to ensure complete test coverage. Only test analysts with extensive domain knowledge and lots of testing experience usually succeed this way. Quality testing often fails to provide complete identification of the launch risk, making the enterprise vulnerable upon launch. In manual testing efforts, often there's no time to test. Automation usually occurs too late to shorten time-to-market. Jim explains how he escaped this dilemma at Egreetings.com, a top 50 website.

This article is intended for Sr. Management or those involved with driving change within their organizations. The paper provides insights on why companies should be concerned about managing software risks and presents a foundational set of recommendations in getting started with addressing what the author views as a "Productivity Crisis in Software."

Ms. Dekkers and Dr. Zubrow talk about the global perspective on high-level maturity organizations.

Staff turnover, mis-sizing a project, inflation of size during the project, failure to specify, and variation in delivery rates are the top risks common to all IT projects. Listen as Ms. Dekkers and Mr. DeMarco talk about coming face to face with risks in software development projects.

This article explores the differences between software and content development and suggests tools that can aid development, through the automation of processes.

In major companies, one out of every four expense dollars is spent on information technology. As IT becomes more important to business, it has to be run as a business--be market competitive, be market ready, offer the customers options, manage itself with a strong fiscal accountability, treat the money it's responsible for as an investment. The notion of running IT as a business really means making IT competitive through the regular market pressures of the business that houses it, and more and more companies are understanding this.

A two-stage approach to transforming quality control to quality assurance: Quality Assessment (Stage 1) provides objective quantitative evaluation of quality while identifying and fixing software defects early in the development cycle, before they get to the customer and even before testing; Quality Assurance (Stage 2) helps prevent defects from entering the code base by enforcing coding standards during, and by preventing new defects from occurring during times of change through accurate impact analysis.

Those who talk about software development process seldom forget to mention the importance of a project post mortem. All books on process management that I have read and all company Web sites that I have visited have something to read about project post mortems. And my concern here is, do we realize the importance just because everyone else is talking about it or are we committed to use it because the concept sounds relevant? And if we are committed, then how do we take the best out of it?

Updates are costly and disruptive. Plan to make certain that your updates are successful.

About the Show: Ms. Dekkers and Mr. Yourdon discuss bottom-up quality, CMM, and eXtreme Programming.

Every once in a while someone will ask me what I do for a living. When I tell them I am a software quality management consultant, I usually get a blank stare and something like "Oh, that's nice." Politeness keeps them from asking what SQM is.

The challenge was to introduce agility (Scrum) across the AOL Publishing organization. If we subtract the editorial staff, the agile transformation affected roughly 3,000 employees one way or the other. The agile consultant and coach tried to tackle several issues under one “reward and recognition program” umbrella. For example, “How do we know that the 50-70 project teams, who were working in parallel at any given moment, were really doing agile?”

Testers and developers require unique skills, which are very complementary in nature. Both the test teams and development teams should understand this to be more productive and to reach our common goal of producing quality products. By demonstrating the value of the test teams and development teams to each other, we gain mutual respect for each other. As we are seeing now, testing is being recognized as a profession by itself. It continues to grow stronger and finally reaches a stage where it is inseparable from development.

This paper discusses issues that have proven to successfully assemble responsive testing teams. If done properly, the team becomes a value added extension to the quality process. The issues discussed are not all the issues by any means. Nor are the proposed methods of dealing with these issues the only way to do so.

Internet time. Sometimes you feel like a mouse running ever faster through the maze, toward elusive cheese that frustratingly moves from place to place. "Naturally," says the head mouse, "we have to take some shortcuts to get to the cheese on time." So maybe you don't have time to talk to users, or have a human-factors specialist design the user interface, or execute a rigorous test suite. But that's okay, you'll beat the competition to the marketplace and that's all that counts, right? No. Quality still counts, too.

Rapidly changing application code and Web content can be a challenge for any eBusiness to manage. Requests from partners, customers, suppliers, and development teams must be tracked and implemented in an orderly way, with strong auditability. At stake is the quality of eBusiness applications, the accuracy of Web content and the ability to deliver both in a timely manner. This paper talks about how to manage the entire development lifecycle.

In this paper we describe an investigation of a part of testing folklore: that long tests are more likely to find bugs than short ones.

To survive, the Test Manager has to demonstrate the effectiveness of the Testing Process. The evidence to show this is required to be more than software defect metrics - how many raised, how many outstanding/fixed by severity and urgency etc. It needs to be comprehensive measurement of the code being tested and of the testing service provided to test it.

Web development may be distinguished from traditional software development by descriptive terms such as "slam it and jam it," "FAD--Frantic Application Development," or "Wild Web Developer." These phrases from Glass' column help us understand the new challenges faced by test and QA people who are assigned to Web projects. In this column, Glass identifies many of the new aspects of testing that come with the advent of Web software.

The Graybox Testing Methodology is a software testing method used to test embedded systems. The methodology is platform and language independent. The current implementation of the Graybox methodology is heavily dependent on the use of a host platform debugger to execute and validate the software under test.

In this paper, the authors describe their experience with automatically testing Java virtual machines and describe two specific techniques for generating test cases.

The PERF (Process Enhancement Request Form) template was created to promote continuous process improvement. Anyone in the organization can submit a PERF to add, change, or remove anything having to do with processes.

As testers we typically receive software from a development group at the end of the build cycle and then install this software into a given test system. We then run a set of pre-written test cases that exercise the software in a way that tests the software in a simulated environment. These tests generally take one of 3 forms. 1) We examine manually or programmatically the UI screens that the software produces. 2) We test the objects and methods of those objects in the program by exercising test code that interacts with the product code. 3) We do a "System Test" or black box test that places the product in a simulated user environment and then we do the operations that an end user would and verify the results.

This paper accompanies a STAR presentation that takes the participant on a journey through the long-term effort to transform a manual test-tracking approach to a database-drive approach.

This paper defines testability and discusses its importance for software applications. We take a look at why it gets left out of most software components and why it needs to be there right at the design stage of the software development life cycle. It also examines common software controls from a testability point of view and suggests improvements that should be made to ensure better testability.

Three years ago, the NYSE and SIAC established an initiative to improve the productivity and quality of testing. This paper discusses the key architecture and infrastructure elements of that initiative including: The suite of tools needed to test and control 20 major software systems that are written in many different computer languages, operate on heterogeneous  hardware platforms and operating systems, and are in a constant state of change;
The development, operation, and maintenance of robust, reusable business-oriented Regression Scripts; Key issues and lessons learned.

Data centric products such as language and language-based logic products can pose an overwhelming test problem. Here is an approach to begin defining an omniscient test suite to attack search engine bugs using model-based testing theories in the real world.

By performance testing your Web systems before they are elevated to production, you will know in advance what needs to be beefed up for the "big day." At Vanguard, our biggest day happened over the Y2K weekend when many of our clients logged in to check on their life savings. This presentation will go through how we prepared for this event and how you can do the same.

The development of a test strategy is a means of communication with the customer commissioning the test on such matters as the organization of testing and the strategic choices that go with it. The test strategy indicates how testing is to be carried out. In order to make the best possible use of resources and time, it is decided on which parts and aspects of the system the emphasis should fall. The test strategy forms an important basis for a structured approach to testing and makes a major contribution to a manageable test process.

This paper details some of the lessons I learned in my first assignment managing outsourced testing. It explains how we can find equilibrium between managers and testers and between internal and external people, what we can do to ensure that the product maintains our high standard of quality, and how we can prepare for and respond when things go wrong.

Testing has never been easy, but when it comes to large institutions, things can get terribly complex. Take large banks for example. For years they developed their own solutions, building applications and bringing in all kinds of hardware and software available, in order to provide their customers with better products and services. Most of the times buying decisions were taken on the go, following no architectural model or plan, which, unfortunately, led them to rely on modern Frankensteins (a.k.a. automated beasts ) to take care of their most valued asset: their customers.

Today component engineering is gaining substantial interest in the software engineering community. Although a lot of research effort has been devoted to analysis methods and design strategies of component-based software, few papers address the testing of component-based software. The paper identifies and classifies the testing issues of software components and component-based software according to working experience.

The objective of this paper is to provide insight to the integrated processes, financial and resource requirements, and technical components necessary to achieve a robust end-to-end test environment.

A fully integrated environment will enable end-to-end testing, quality improvement and pre-production certification for your suite of applications. The presentation further examines the vision, components, approach and methodology, and business processes that are critical to a successful test environment.

The purpose of this paper is to provide some practical guidance for understanding and computing cost and benefits from test automation. It describes some financial, organizational, and test effectiveness impacts observed when software test automation is installed.

Use Cases are used to specify the required functionality of an Object-Oriented system. Test cases that are derived from use cases take advantage of the existing specification to ensure good functional test coverage of the system.

The challenge for testers: reduce the testing interval without reducing quality. One answer: find a new way to approach test design and test generation. This paper will discuss an ongoing Lucent Technologies experiment in automated test generation from a behavioral model of the software product under test. Results indicate that our new approach can increase the effectiveness of our testing while reducing the cost of test design and generation.

Mutation Testing is a powerful method for finding errors in software programs. This paper will describe the process of mutation testing and how a new approach to this technology benefits the software industry.

In 1993, we at USA Group chartered a project to replace its 15-year old student loan guarantee system. The new system was named EAGLE II and recently entered production. USA Group is driven by its software systems. As a consequence, software development is strategic to the company's success. We've had significant experience in creating and maintaining large systems. However, our experience in creating those previous systems left us looking for a better way.

I have heard testers lament about being managed by non-technical people who cannot tell the difference between a PC and a microwave oven (they both have windows, don't they?)! Managers believe in management, and we technical people believe in subtler, sophisticated, deep technology. The concept is simple. Then I was subjected to a harsh reality!

Software professionals have long engaged in debate over software development processes. Much has been written about how to improve those processes-resulting in better-quality, faster-to-market products. Often neglected are the people who implement the processes. Developers and testers frequently seem to have adversarial relationships, although they share the same goal: high-quality software. No matter how good they are, the processes are unlikely to succeed if the participants fail to get along.

Relentless Application Development is our term for continuous, rapid development and deployment of mission critical applications in highly changeable environments.

Time sensitive development; Rapidly evolving new technology and methods; Computing technology is changing very rapidly, giving more power for less money.

When testers are left with a mess on their hands, what should they do? When this column appeared during StickyMinds' first month, October 2000, it provoked several reader comments. In it, Bret Pettichord asks the question: "Is it the tester's fate to 'work the clean up crew?'"

Risk management must be fully integrated into all the development and maintenance processes for systems. It involves more than applying risk assessment methods to identify and evaluate system risks. To explain this broad approach to risk management, this paper discusses the way in which Requirements Driven Management (RDM) methods contribute to handling risks.

Software testing and quality are vitally important topics--but they are also deadly dull, real yawners the way most people talk about them. In this column, the author explains why that is so, and offers some suggestions on how to overcome the problem. Basically, he says, people are trying to make a managerial sow's ear out of a technical silk purse.

When we mindlessly use templates to give easy answers, we're trying to play chess with a checkers mentality. That's David Gelperin's warning in this article. Templates related to context-sensitive issues require a lot of analysis. As he aptly suggests, "Perhaps every test doc template should come with a warning label: 'Not a Substitute for Thinking.'"

When people on the project team disagree, it helps to be able to understand assumptions and to sort through the feelings and the facts that influence team dynamics and the decision-making process. In this article Peter Grazier provides useful insights for understanding these influences.

The object-oriented class testing approach, proposed in this paper, combines functional with structural testing techniques. Based on state-based testing, test cases generated from the MACT (Method for Automatic Class Testing) tool can be used to execute functional testing.

This paper focuses on the successes and issues associated with developing a statistical testing environment for an industrial software project. The paper will also describe how both statistical testing based on software models and traditional testing based on unit and other functional tests can be combined into an effective approach to testing large software intensive systems.

What follows is a list comprising a sample body of knowledge for software testing which strives to be inclusive of the many facets of this subject area.

This is a presentation on the benefits and risks of a tester certification effort.

Several years ago, two process improvement initiatives combined to produce the ACSIS Earned Value Tracking System (EVTS): the development of SDWT's and the attempt to devise a more desciplined way to perform project planning and tracking. The two endeavors became mutually supportive. This presentation describes the ACSIS EVTS development, process, and results.

Testing is crucial to e-commerce because e-commerce sites are both business critical and highly visible to their users; any failure can be immediately expensive in terms of lost revenue and even more expensive in the longer term if disaffected users seek alternative sites. Yet the time pressures in the e-commerce world militate against the thorough testing usually associated with business criticality, so a new approach is needed to enable testing to be integrated into the development process and to ensure that testing does not present a significant time burden.

The very familiarity of much of the technology means that tried and true mechanisms will either be suitable or can be modified to fit. Rapid Applications Development (RAD), in particular, suggests some promising approaches. Like most new ventures, though, e-commerce must find its own way and establish its own methods. In this paper we have suggested some testing principles that have stood the test of time and interm

This Unit Testing template has been used for small to mid-sized, HTML-based Web sites.

This paper describes one of HP Division's experiences in starting an initiative that significantly changed the way in which its managers, engineers, and marketing specialists understand and implement product requirements management.

The experiences detail how, by maturing our requirements management practices, our organization was able to address the following issues: 1) information redundancy and synchronization, 2) inconsistent documentation format and content, 3) inefficient requirements elicitation, communication, and review procedures, and 4) lack of customer focus. The paper also offers recommendations for those organizations that plan to start a similar initiative. Finally, it discusses plans to improve our requirements practices on future projects.

This paper describes a case study of the Rockwell Collins approach to repository automation, specific examples of tools implemented, and benefits realized through automation.

This paper describes a pilot project that utilized this process and provided lessons-learned for those who wish to use this process in the future. This paper does not discuss issues related to recruiting, phone interviews, final hiring decision and success criteria set by the human resources (HR) department.

This paper is focused on the great need for software testers to ensure the quality of software being prepared in different languages and locations. In a presentation and accompanying paper, Jeff Jewel discusses such issues as GUI differences, special character sets, formats and standards, multiple versions of software, and cultural aspects of testing.

Testing is getting harder. To keep up with ever growing complexity of software and the testing task, new approaches to test development must be used. One of these approaches is automated test design based on precise models of software behavior and usage.

Today, commercial support in this area is weak. There is a current and growing need for a variety of commercial tools supporting automated design.

The purpose of this presentation is to provide insight into the information requirements for automated test design to (current and potential) vendors of software modeling tools. It is hoped that this information will catalyze a number of commercial development efforts.

Quote from the abstract: "It is widely believed that the adoption of predefined processes aids the productivity and quality of software development. Furthermore, it is widely believed that the adoption of these processes at the enterprise level provides advantages of repeatability and organizational maturity that amplify the benefits. Unfortunately, the existing corpus of software engineering practice standards has been targeted for adoption at the project level rather than the enterprise level. A new standard, IEEE/EIA 12207, Software Life Cycle Processes, addresses this problem--it is intended as an integrating, organizing, strategic standard specifically directed to enterprise adoptio

This article is a basic introduction to the concepts of Software Risk Management. It includes discussions of: Identifying the Risks, Analyzing the Risks, Building the Risk Management Plan, Tracking and Controlling to the Plan and Learning from Experiences.

Launching a new product line is a difficult and time-consuming task under the best circumstances. While working on a new project can be refreshing, difficulties arise in allocating sufficient resources to create and tune the new product development processes. Modifying the processes or Best-Known Methods (BKMs) of the past is one technique employed to allocate time and resources more effectively. Transferring BKMs from an earlier product line into the current one can bring about its own set of challenges which include: defining the BKMs, producing repeatable BKMs to be deployed in varied environments, implementing techniques to log the BKMs, and placing the BKMs in a central location. This paper discusses one approach to transfer software BKMs between generational product lines. The topics addressed include: defining the project's mission and goals; creating definitions and processes to support the BKM transference; encountering and solving issues while implementing the processes.