Samuel Prasad, Ph.D.

2012 Technology Predictions

There are three things in life that are certain - death, taxes and the crystal ball dropping in Times Square (New York City) on New Year's Eve. Truth be told, I did not really see the ball drop this year because the TV channel that my wife and I were watching got to the ball only after it had slid almost to the bottom of the pole. Anyway this is a good time to peer into the crystal ball and make a few predictions for 2012. While most of the experts seem to be fixated on the number 10, I'll limit my predictions to THREE. Here they are:

1. THE SMART PHONE REPLACES YOUR WALLET AND YOUR ID

NFC (near field communication) equipped smart phones will be widely available in the U.S. through most of the major carriers before the end of 2012. How does NFC work? The technology behind NFC uses inductive coupling to transfer data between two NFC-equipped devices when they are within a few centimeters of each other. Europe is way ahead of us in the use of NFC-equipped smart phones as a payment method and for identification purposes. The customer just taps the phone at the POS register instead of swiping a credit card. This method of payment is quite secure because of two-factor authentication which requires the customer to key in a PIN or through biometric scanning of the customer's fingerprint. Multiple credit cards, store cards, loyalty cards and bank accounts can be linked to a single NFC phone which means that a wallet full of cards is on its way to becoming obsolete.

The ability of a smart phone to display 2-D bar codes or other visual tags will increasingly be used in lieu of boarding passes at airports, driver's licenses and other forms of paper identification. NFC phones used in conjunction with two-factor identification eliminates many of the problems with stolen IDs and credit cards.

By the year 2015, at least 30% of the people will be "wallet-less".
 

2. ENTERPRISES STAY AWAY FROM THE PUBLIC CLOUD

Companies will continue to stay away from the public cloud because of security concerns. Security in the public cloud is still very elusive. According to Vivek Wadhwa, a columnist for Bloomberg Businessweek and the Washington Post, "Cloud computing provides significant cost savings and operational advantages. But it also unleashes a Pandora’s box of security concerns. We’ve already seen cloud break-ins originating from China. And a number of legitimate Internet companies have suffered when the FBI confiscated a shared server in a cloud hosting facility that also hosted rogue applications."

A "public cloud" means that a company's applications and data are hosted on servers and networks that are outside the company's firewall managed by a third-party, which means that the company has to rely on the cloud service provider to safeguard the company's application and data. The public cloud will still gain popularity among start-ups for testing new products because of the cost benefits it provides.

Hybrid Clouds are beginning to emerge, but I am not sure if they will be able to address all the security concerns adequately. What are hybrid clouds? They are a combination of public and private clouds where some of the company's software and/or data resides on the public cloud and some on its private cloud which is essentially the company's internal network.

Cloud service providers have a long way to go before enterprises will entrust their applications and data to the public cloud.

3. THE AGILE MANIFESTO IS ADOPTED BY MORE COMPANIES

The majority of technology projects are behind schedule, over budget and/or does not meet specifications according to the results of a study published earlier this year by "The Standish Group". The primary reason for this high rate of failure is the continuing use of outdated project management methods that rely on a command-and-control approach where most decisions related to design, cost and time are made at the top based on incorrect information. Management is lulled into a false sense of security when they buy into the notion that projects can be executed successfully by creating detailed plans upfront, when many of the parameters and constraints needed to create such plans are yet unknown. We've all heard about the urban myth that a project plan must spell out everything in minute detail including the condition “..in case someone falls under a bus..”.  This is a hangover from the DoD standards. If you are building nuclear reactors it’s a good idea to spell out everything and back-up every decision with a series of checks and signatures. But most of us are not building nuclear reactors, and for management to insist that project plans be created with an excruciating level of detail that is both unnecessary and inaccurate before the project can even start is ludicrous. (see http://www.iso-9001-checklist.co.uk/tutorial/4.2-documentation.htm).

In order to increase the probability that a project will be successful it is my opinion that the only solution is to adopt the "Agile Manifesto". It is refreshing to see that it is being adopted by more and more companies as they realize that traditional project management is just not working. The manifesto for agile software development is as follows:

• "Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan."

The twelve principles behind the Agile Manifesto are:

• "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

More information about the agile manifesto can be found at http://agilemanifesto.org/.

I believe that companies will have no choice but to adopt agile management processes to not only retain their best talent but also to stay competitive in today's global market.

The Year of BIG DATA

Happy New Year!

"Let this coming year be better than all the others. Vow to do some of the things you've always wanted to do but couldn't find the time. Call up a forgotten friend. Drop an old grudge, and replace it with some pleasant memories. Vow not to make a promise you don't think you can keep. Walk tall, and smile more. You'll look ten years younger." - Ann Landers

Unlike the hundreds of thousands of people who braved the cold and thronged to the crossroads of the world - the heart of Times Square in New York City - to watch the ball drop at the stroke of midnight to usher in 2012, many of us were quite content to sip champagne and watch the events unfold on television from the warmth of our living rooms. Here is an excerpt from an editorial written by me that appeared in the January 2012 issue of The Quality Islander.

The New Year brings with it anticipation of new opportunities. In order to capitalize on these opportunities we need to be able to identify business trends and develop strategies that will deliver products with just the right features, reduce operational costs and improve service to our customers. How do we do this? Very simple! Understand customer behavior. This is where the ability to comprehend "Big Data” becomes critical for businesses to stay competitive and profitable.  IBM defines big data as the "2.5 quintillion (2.5 followed by 18 zeroes) bytes of data we create every day from sensors used to gather climate information, posts to social media sites, digital pictures and videos posted online, transaction records of online purchases, and cell phone GPS signals, to name a few. Ninety percent of this data has been created in the last two years alone."

I have spent much of last year working with big data. Until a year ago it was only the Internet companies who were interested in analyzing big data comprised mostly of click stream information to better understand the visitors to their web sites so that they can deliver advertisements with personalized contents. This type of data analysis, called data mining, is now increasingly being used by many companies including utilities, media companies, hospitals, banks and retailers. For example, utilities have started to mine data to predict customer demand for electric power and monitor the efficiency of the distribution grid. Media companies that deliver programming via the Internet or cable are now able to monitor in real-time the demography of their customers watching their content. This information can be used to develop customized programming at the household level and for targeted marketing.

Unfortunately, as big data grows there is a continuous erosion of our privacy because the results of the analyses of big data, called business intelligence (BI), are increasingly being used to make decisions that affect our everyday lives. BI used by hospitals directly determines the quality and type of medical care delivered to patients. BI used by banks determines the cost at which a customer can borrow money, which implies that not only must big data be clean but also the right metrics and models must be used to analyze big data.  As the volume of big data increases the complexity of the analyses can afford to decrease, according to a Gartner report which says, “Today, data mining is really about building sophisticated models with not very much data. Now, big data gives you huge volumes of data which means that you don’t need as sophisticated a model anymore.”  In other words, the cleanliness, consistency and integrity of data will be at least as important as the level of complexity of the analytical models.  In addition, non-traditional types of databases will be needed to store, classify and quickly access unstructured data from social media.

There are many new technologies scheduled for release this year that will help us better manage and understand big data. In order to stay competitive, companies will do well to carefully evaluate these new technologies for adaptability and scalability to make sure that the technology they choose is aligned with the types of data they collect and the needs of their customers.

Risk mitigation during software development

9th Annual Fall ASQ Conference
on
Risk Management

Presented by
Samuel Prasad, PhD, PMP, CSQE
Farmingdale State College
Friday, November 4th, 2011

Risk analysis and prioritization during the software development life cycle are key to controlling quality, managing costs and bringing a product to market on time. Learn the agile approach to risk analysis and how to identify applications that require more stringent testing because they are prone to higher risks. The results of risk assessments are used to create test scenarios and select specific test cases aimed at eliminating much of the defects prior to the construction phase. Most postmortems of software development projects indicate that construction costs could have been controlled and defects reduced if risk assessments are iterative and continuous throughout the development life cycle.

Click here to view presentation.

Data Quality - metrics must match business processes to get the best results!

What is good quality data?
Good quality data means that all master data is complete, consistent, accurate, time stamped and industry standards based.

What is the advantage of good quality data?
Good data quality will improve internal business processes for manufacturers, retailers, wholesalers, intermediaries and other third parties.

Will this add costs?
Instituting any data quality/accuracy program will involve additional resources, very much depending on the size of an organization and experience with data quality management.
But improving the quality of data from end-to-end will reduce costs, improve productivity and accelerate product speed to market. Poor data quality affects businesses negatively. It is hard to improve data quality if the relationship between data quality and business performance can be quantified. The challenge is to identify DQMs (data quality metrics) that are tightly coupled with business processes.

The following is an article written by David Loshin in Information Management Magazine, May 2005.

What makes a DQM?
More challenging, however, is that the individuals typically tasked with devising good DQMs are better trained at data analysis and less skilled in business performance monitoring. Therefore, part of this strategy is to understand the characteristics of a reasonable business performance metric and then explore how to map those characteristics to the measurable aspects of data quality. The following list of characteristics, which are by no means complete, should give some guidance as to how to jump-start the strategy:

o Clarity of definition
o Measurability
o Business relevance
o Controllability
o Representation
o Reportability
o Trackability
o Drill-down capability

Clarity of definition
Because the metric is intended to convey a particular piece of information regarding an aspect of business performance in a summarized manner, it is critical that its underlying definition be stated in a way that clearly explains what is being measured. In fact, each metric should be subject to a rigorous "standardization" process in which the key stakeholders participate in its definition and agree to the definition's final wording. In addition, it is advisable to provide the metric's value range, as well as a qualitative segmentation of the value range that relates the metric's score to its performance assessment.

Measurability
Any metric must be measurable and should be quantifiable within a discrete range. Note, however, that there are many things that can be measured that may not translate into useful metrics, and that implies the need for business relevance.

Business relevance
The metric is of no value if it cannot be related to some aspect of business operations or performance. Therefore, every desirable metric must be defined within a business context with an explanation of how the metric score correlates with a measurement of performance. More desirable is if performance measurement can be directly associated with a critical business impact; this is probably the most critical characteristic of a data quality metric.

Controllability
Any measurable characteristic of information that is suitable as a metric should reflect some controllable aspect of the business. In other words, the assessment of an information quality metric's value within an undesirable range should trigger some action to improve the data being measured.

Representation
Without digressing into a discussion about the plethora of visual "widgets" that can be used to represent a metric's value, it is reasonable to note that one should associate a visual representation for each metric that logically presents the metric's value in a concise and meaningful way.

Reportability
From a different point of view, each metric's definition should provide enough information that can be summarized as a line item in a comprehensive report. The difference between representation and reportability is that the representation will focus on the specific metric in isolation, while the reporting should show each metric's contribution to an aggregate assessment. In turn, this allows the manager to evaluate the priority of any issues needing resolution.

Trackability
A major benefit of metrics is the ability to measure performance improvement over time. Tracking performance over time not only validates any improvement efforts, but once an information process is presumed to be stable, tracking provides insight into maintaining statistical control. In turn, these kinds of metrics can evolve from performance indicators into standard monitors, placed in the background to notify the right individuals when the data quality measurements suddenly indicate a deviation from expected control bounds.

Drill-Down capability
In recognition of the summarization aspect of a representation of a data quality metric, the flip side is the ability to provide exposure to the underlying data that contributed to a particular metric score. The natural instinct, when reviewing data quality measurements, is to review the data instances that contributed to any low scores. The ability to drill down through the performance metric allows an analyst to get a better understanding of patterns (if any exist) that may have contributed to a low score, and consequently use that understanding for a more comprehensive root-cause analysis. This kind of insight allows your organization to isolate the processing stage at which any flaws are introduced and, in turn, enables you to eliminate the source of the introduction of data problems (instead of the typical, counterproductive reaction of correcting the data values themselves).

The challenge
Developing key performance indicators for information quality is clearly a challenge, mostly because the hard numbers presented by data quality tools are typically out of the business context. Here we have provided some insight into how the data analyst can work with the business customer to identify ways that poor data quality impacts the achievement of business objectives and subsequently determine hard costs associated with each occurrence of a flaw. Once this has been done, providing a dashboard with tracking and drilldown capabilities establishes a value-added approach for value-directed information quality management and improvement.

It's the Data, Stupid! Why data is an organization's most important asset.

In the beginning there was the ODS or operational data store - typically a collection of tables in a relational database. The ODS contained the company's raw data which was used to run historical reports on past transactions. Then came the data marts (DM) essentially a snapshot of the ODS. The BI Analysts who were highly skilled statisticians and mathematicians ran queries against the DM, extracted data from the DM and performed their analyses. But all the analyses in the world could not deliver critical information in a timely manner to help management make better operational decisions to improve customer service and help the bottom line.

The good news is that DMs and Business Intelligence (BI) have evolved significantly over the past decade. It is no longer acceptable to have DMs that are just time-stamped snapshots of the ODS. The raw data in the ODS has to be cleansed, massaged and distilled...and I mean distilled...into useful information stored in formats like, cubes, dimensional entities and aggregates in columnar structures at various levels of granularity and recency so that the analysts can visualize, manipulate and study the data from different angles.

What has changed in BI in the past decade?

Data Frequency - real-time or close to real-time
Daily or weekly snapshots of the ODS are no longer acceptable for making decisions. This means that we need to have intra-day data marts as close to real-time as possible that contain only a subset of data that renders recent customer transactions and activities very quickly. Intra-day snapshots of data are trickle fed through data filters into real-time data marts, allowing operational personnel the ability to analyze events occurring during the day of the event. As you can imagine, this means that the volume of data being stored increases substantially. The main ODS and OLAP data mart now contain tens of terabytes to hundreds of terabytes (even petabytes!) to support all forms of BI now. And it should be noted that the granularity of the data for operational BI must be at the lowest level of detail. All this means that, not only does the ODS and OLAP DM infrastructure have to handle faster, more frequent loads of data, but seamless scalability is mandatory – whether it is for storing and processing increased volumes of data, or maintaining the integrity of the environment (backups, failovers, etc.)

Performance - instant gratification
While performance in traditional BI environments has always been important, it is now critical that responses to queries against the intra-day real-time data mart be almost instantaneous. In many instances, requests originate from and responses are received on handheld wireless devices. Communication is no longer one-way. In other words, users are able to send back comments and feedback which contain valuable information (unfortunately in unstructured textual format in many instances) that must be captured, parsed, stored and fed into the ETL process. Add to this the fact that the environment must still support traditional BI users. A mixed environment with ODS, the traditional data mart (OLAP) and the real-time data mart means the software must have the ability to prioritize and route queries, not only according to their importance to the enterprise but also based on data and response requirements.

Number of users - scalability
There was a time when Business Intelligence was the domain of only statisticians and mathematicians who extracted data from historical snapshots of the ODS to perform their magic. Gone are those days. Now BI and analytics are used by business users and even customers want to get into the act since they want access to their transaction history and past experiences at a particular store or web site. Here's another catch. Not all users are human. There are web-bots that roam in and around the data marts trying to detect patterns, do simulations and project outcomes. All of this puts a tremendous strain on the network, server and infrastructure that must be horizontally and vertically scalable to support the onslaught of requests, queries and analytics being thrown at them.

Unstructured Data - Facebook, YouTube, blogs and other social media
Unstructured data is increasingly being used to make critical decisions. The ETL process has to be retooled to handle different forms of textual, audio and video data. The technical challenges that this poses are quite steep since most BI environments are just not set up to handle unstructured data. The space requirements of the ODS and data marts are expected to grow exponentially  because of this; processing capabilities required to parse and convert unstructured data into a structured format puts a tremendous strain on the processing and infrastructure requirements, which in turn has a direct impact on scalability and performance.

The following diagram illustrates a typical BI system of today.

  
 

While the "Daily ETL" process takes in data from all data sources to perform incremental updates on the ODS and OLAP data mart, the "Real-time ETL" also called an intra-day ETL accepts transactions through a filter configured to feed only transactions that are deemed to meet the "recency" criterion. This essentially limits the data to transactions and customer behavior that are needed to make decisions based on events occuring during the day. Unstructured data coming back from a customer's handheld device is staged in a daily customer tracking DB and fed into the "Daily ETL" process along with data from all the regular data sources. It is also fed into the "Real-time ETL" process so that it is immediately available in the Real-time data mart.

Data marts and BI systems of the future must be completely rules-meta-data-driven capable of self-learning and able to modify their behavior based on usage and data types that are yet unknown.

Future of BI Analytics

The future of Business Intelligence (BI) Analytics rests on emerging technologies that will use special hardware appliances that will effectively mine data at tremendous speeds and perform predictive analysis and extrapolate trends using simulation in real-time. Traditional BI products, including dashboards and ad hoc queries use historical data to generate reports, which only tell the story of what happened in the past. In future, predictive analytics, alerts and extrapolation of trends will become common practice through the real-time exploitation of informational patterns hidden in historical data to project what might happen.

Hardware appliances like IBM's Neteeza and Oracle's Exadata provide extreme performance in both OLTP and OLAP models, allowing for very quick deep dives into the data specifically in the latter environment. These appliances are effectively supercomputers that can chew through large volumes of data very quickly.

In addition, the increasing popularity of columnar databases like Sybase IQ, HP Vertica and ParAccel allow data mining software to access a specific type of data or fact based on an attribute or dimension must faster than traditional row-based databases because in a columnar database, each data page is populated with data from only one column. 

Tom Davenport and Jeanne Harris in their book "Competing on Analytics" postulate that in the future more automated decisions using "operational business intelligence" will be made by machines rather than relying on humans. It will no longer be acceptable for companies to wait days or weeks to extract data from transactional OLTP systems, load it into data marts and then run historical reports through queries. There will be more prediction and less reporting. There will be greater use of alerts to notify managers immediately when key indicators are at undesirable levels.

Another area of data mining that is almost non-existent toady is the mining of unstructured or textual data. With the ever increasing popularity of social media there is an urgent need to develop efficient parsers to analyze unstructured textual data and transform them into information that can be used in predictive algorithms to project future behavior.

Many of the above changes will hopefully be driven by companies who want to be at the top of their game and increase customer satisfaction. Ultimately the companies with the best analytics will have the most efficient marketing campaigns and promotions.  Their customer service will be the envy of their competitors. They will use just-in-time inventory and employ the best people in the industry compensated directly based on their contributions to the company. They will be the leaders who will outperform their competitors and lead us into the future.

Software Quality Metrics

The indicators used to measure software quality are usually classified into two groups - end-product quality metrics and in-process quality metrics. The study of the relationship between in-process and end-product quality metrics is the main focus of software quality engineering. It is not surprising that results of numerous studies conducted at Motorola and IBM have found that improvements in in-process quality almost always translate to an increase in end-product quality.

END-PRODUCT QUALITY
End-Product Quality metrics consist of:

• Defect density
• Mean time to failure
• Customer problems
• Customer satisfaction

Defect density is a measure of the number of defects relative to the size of software, which is a function of the number of lines of code (LOC). The standard definition of LOC used in software engineering is any line of program text that is not a comment or blank line, regardless of the number of statements or fragments of statements on the line.

A simplistic definition of defect density is the number of defects discovered over a specific period of time divided by the size of software expressed in thousands of lines of code (KLOC).

The mean time to failure (MTTF) is defined as how long the software can run before it encounters a "crash".

Defect density and MTTF are correlated - a software program with higher number of defects is likely to crash more often than a software program with a lower defect density. It is important that defects (or bugs) that are associated with a low MTTF are identified and removed early. The defect density is also important for another reason because it is used as one of the factors in computing the cost and resource estimates of the maintenance phase of the software life cycle.

Customer problems - while defect density and MTTF are useful to drive quality improvement from the development engineer's point of view, it is equally important to consider the customer's perspective. All problems reported by the customer - not just valid defects - are counted as customer problems. Usability problems, unclear documentation, and duplicates of valid defects (i.e., defects reported by customers for which fixes or work-around solutions are available, but the current customers are unaware of them) make up the problem space from the customer's perspective. This metric is expressed in terms of Problems per User Month (PUM), which is the total number of customer problems reported in a specific time period divided by the number of users divided by the number of months in the reporting time-period. PUM is usually calculated every month after the software is released to arrive at a yearly average.

To reduce the value of PUM:

• Reduce defect density and increase MTTF.
• Improve usability.
• Provide clear documentation.
• Improve customer training and support.

The fourth metric - customer satisfaction - is measured by customer survey data via a typical 5-point scale:

• Very satisfied
• Satisfied
• Neutral
• Dissatisfied
• Very dissatisfied

Based on the 5-point scale several types of analysis can be conducted using:

• Percent of completely satisfied customers (Very satisfied)
• Percent of satisfied customers (Very satisfied and satisfied)
• Percent of dissatisfied customers (dissatisfied and Very dissatisfied)
• Percent of unsatisfied customers (neutral, dissatisfied and very dissatisfied)

IN-PROCESS QUALITY
In-Process Quality metrics are less formally defined and varies depending on the make-up of the software engineering team - higher the skill level and domain knowledge of the team, less is the use of in-process quality metrics. However, the goal is to learn how to engineer quality into the process so that the end-product quality is consistently high.

In most cases, in-process quality metrics means the detection and tracking of defects (bugs) during software testing. This is costly and not very effective in increasing end-product quality. However, there are several organizations with well-established mature processes where inspections are conducted at every phase of the software development life-cycle (SDLC) not just during the testing phase.  A defect that is detected at a later phase is much more expensive to fix than if it was either prevented or detected and fixed in an earlier phase of the SDLC. Inspections are carried out to specifically identify defects in architecture, interfaces, logic, and documentation at every phase - inception, elaboration, construction and testing - of the SDLC by reviewing the high-level design, low-level design, code and documentation.

All the new studies, once again, prove the old adage to be true - quality cannot be inspected into a product!

To steer a boat you have to move to the back.

This is quite contrary to the theories developed by Kurt Lewin, Ronald Lipitt, and Ralph White in 1939 which state that there are only three major styles of leadership:

• Authoritarian
• Participative
• Delegative

Authoritarian style of leadership assumes that the leader has all the information necessary to make the right decisions. For this style of leadership to succeed employees must unconditionally accept the power of the leader and follow directions without questioning them. It does not mean that the leader can use demeaning language, engage in abusive or unprofessional behavior. As you can well imagine, this style of leadership may work well in the military but it rarely achieves the desired goals in a non-military work setting. Why? People don't like to be ordered to do things without explaining the rationale for the directives and without a clear understanding of the end goals. 

The participative style of leadership is much more common in companies where the leader includes one or more employees in the decision making process. The leader still makes the final decision and is responsible for the outcome of the decision. This style recognizes the strength and knowledge of key employees and is a sign that the leader is secure, confident and is not afraid to seek counsel from others. This is a style that most employees respect.

The delegative style of leadership must be used wisely and only if the leader has the full trust and confidence of peers and the team. This style of leadership assumes that the employees empowered to make decisions understand the end goals, are able to obtain and analyze the required information before taking any action. This style must be used only if the leader is not quick to blame others even if decisions made by employees causes things to go terribly wrong.

Social scientists over the past century have come up with many leadership theories. Most well known among them are:

1. "Great Man" theories assume that leaders are born, not made.
2. “Trait” theories assume great leaders share particular traits that make them well suited for leadership.
3. “Contingency” theories purports that environmental and external variables, including the type of followers determine the person best suited to lead.
4. “Situational” theories states that people who can recognize situational variables that affect the outcome of an action or decision are best suited to be leaders.
5. “Behavioral” theories are based on the supposition that great leaders are made not born which is the exact opposite of the "Great Man" theories.
6. “Participative” theories suggest that good leaders elicit input from other members of the group before making decisions.
7. Management theories also known as "Transactional theories" are based on a system of rewards and penalties. Good leadership is rewarded for accomplishing the stated end goals while failure to meet them are seen as signs of poor leadership and are punished.
8. Relationship theories also known as "Transformational theories" is the best form of leadership where leaders are able to motivate, transform and inspire their group members. It is no wonder that leaders who belong to this group have the highest ethical and moral standards.


Transformational leaders are ones who have learned the art of leading from behind. They listen to the people around them. They usually surrounded themselves with smart problem-solvers who do not need to be told what to do. Transformational leaders spend their time focusing on what they should be doing to achieve the end goals because they know that the people around them will do the same without  having to be micromanaged or told what to do every step of the way.

"To steer a boat you have to move to the back. Leadership is about asking questions and letting people answer them," says Anne Berkowitch co-founder of SelectMinds a social networking company in New York.

Orthogonal Array Testing Strategy (OATS)

One of the primary goals of software testing is to find the maximum number of defects (bugs) using a minimum set of test cases. There is a testing method that helps achieve this goal called the Orthogonal Array Testing Strategy (OATS). This is a statistical method aimed at maximizing error detection while reducing the number of test cases by using pair-wise testing.

What is pair-wise testing?
Let us assume that the software being tested has 5 variables each of which can assume 4 states. The number of test cases that will be required to test all possible combinations is 4 X 4 X 4 X 4 X 4 = 1024. Researchers at Bell Communication Laboratories in the late 1990s found that most defects were caused by incorrect values of a single variable or by values of certain pairs of interacting variables.

Defects caused by specific states or values of a single variable are called single-mode faults. This implies that we could detect all single-mode faults through 4 + 4 + 4 + 4 + 4 = 20 test cases.

Defects that occur when a combination of two variables assume specific states (values) are called double-mode faults. This is an indication of harmful interaction between two variables when they assume certain values. For purposes of illustration, let us assume that we are able to identify 6 variable-pairs with harmful interactions from among the 5 variables. Each variable-pair will require 4 X 4 = 16 test cases to exhaustively test all possible combinations. For 6 variable pairs, a total of 16 X 6 = 96 test cases will be required.

Thus, using the OATS methodology the total number of test cases required to detect all single and double-mode defects is only 20 + 96 = 116 as compared to 1024 test cases required using traditional test methods.

OATS, in effect, provides a statistical method to test pair-wise interactions through the use of orthogonal arrays. An orthogonal array is a rectangular matrix where rows represent test cases (runs) and columns represent variables (factors) being tested. The different states or values that each variable can assume are called levels. The underlying rationale of this technique is based on the hypothesis that almost all defects in software are due to either specific levels of a single factor or due to pair-wise interactions of factors at certain levels. One of the major challenges of this approach is to identify all pair-wise combinations that give rise to harmful interactions.

However the major advantages of OATS are as follows:

• Lower number of test cases.
• All single-mode and double-mode defects are uncovered which account for more than 95% of the bugs.
• Improved productivity due to reduced test cycles and testing times.

Software Quality

 

The Long Island Chapter (Section 303)
of the
American Society of Quality (ASQ)
presents an evening discussion
on
Software Quality

Every day, companies around the world struggle with issues related to software quality. How would you rate the quality of software developed in your company? How many discussions have you had with your engineering teams or senior management about the quality of your software? Does your company have measurable software quality standards? Are your customers satisfied with the quality of your software? Software errors cost the U.S. economy more than $60 billion annually in actual damages. Software bugs are not just annoying, they can be destructive and deadly.

Learn to recognize and remove defects during the initial phases of software development. It costs 100 times more to remove a defect in the operations phase than during the development phase of the software development life cycle (SDLC).

Presented by
Samuel Prasad, PhD, PMP, CSQE
ASQ LI Web Site Chair

Thursday, June 24th, 6:30 – 8:30 PM
Bertucci’s Restaurant
Melville, NY

Click here to view the presentation.