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.

PMBOK and Scrum are like oil and water? I don't think so..

Project management methodologies based on PMBOK and Scrum have more in common than they are different, which is contradictory to the wide-spread belief that the two don't mix. They are very much the same except for one key difference. Well, both PMBOK and Scrum are controlled by the triple constraints of cost, schedule, and scope. So where’s the difference?
The difference is:  in PMBOK the scope is locked down so that the project schedule and cost can be estimated.
Scrum, on the other hand, embraces scope changes. So it only follows that no attempts are made to lock down scope. Instead Scrum promotes the approach where schedule or cost or both are locked down. This allows the scope or product feature set to be modified as necessary with a view to delivering maximum value to the user in a short period of time. This, of course, implies that Scrum projects, in most cases, are in a perpetual releasable state.

The traditional PMBOK plan-driven approach follows the PDCA (plan-do-check-act) cycle made popular by Dr. W. Edwards Deming, who is considered by many to be the father of modern quality control applies to both PMBOK and Scrum projects.
The following figure illustrates the PDCA cycle in a traditional PMBOK setting.

  

• Plan. Define the project objectives. Understand the requirements. Plan for implementation and delivery.
• Do. Execute the plan in incremental steps. A step may last a few weeks or months at the end of which there are artifacts, including partial system functions, that are made available for review.
• Check. Review the results of the plan execution. Test and analyze the results, identify what worked and what did not.
• Act. Modify the plan based on lessons learned in the "check" step: Go through the cycle again with the new plan to prevent defects in the previous iteration from occurring again.

The following figure illustrates the PDCA cycle in an Agile (Scrum) setting.

 
 

• Plan. Define the project objectives. Understand the requirements. Generate a list of product features called the product backlog. Prioritize the items in the product backlog in concert with users and business stakeholders taking into account the usefulness of a product feature and its associated cost. Create a plan for implementing the backlog items in order of priority. Break up the plan into incremental steps (or Scrums) and identify the backlog items to be implemented in every Scrum.
• Do. Execute the plan. Implement the items that are part of the Scrum.  A scrum typically lasts anywhere from 2-weeks to a month. At the end of the scrum, the product features are fully functional. They have been tested and the results validated as part of the Scrum.
• Check. Review the results of the plan (Scrum) execution. Test, analyze the results and identify what worked and what did not.
• Act. Take action based on lessons learned in the "check" step: Go through the cycle again with a modified plan. In other words, if the product backlog needs to be modified and the items re-prioritized, please go back to step 1 and do so.  Repeat the steps. 


Moving from PMBOK to Agile (or points in-between)
A PMBOK manager who is used to the traditional "command and control" approach must learn to lead from behind (see my blog on leadership styles).  Learn to hand control over to the team. Learn how to ask the right questions at the right time in order to provide guidance and direction to the team. Keep in mind that the manager (or Scrum Master) still makes the final decision and is responsible for the outcome of the decision, but this style recognizes the strength and knowledge of the team and is a sign that the manager is secure, confident and is not afraid to seek counsel from the team. This obviously is a style that most team members respect. One other thing: make sure that the manager knows, understands and believes in the Scrum process. This is important not only to motivate and mentor the team but also is critical to the successful completion of the project.

Good luck on your journey from PMBOK to Scrum or to any points in-between.

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.

Business Intelligence needs better analytics

In recent years many companies have jumped on the "business intelligence" (BI) bandwagon. What is BI? With access to vast amounts of data, BI is definitely not just a collection of reports generated from historical data. BI is also not software that can generate flashy-looking dashboards that provide readings of current key-performance-indicators but provide no actual intelligence based on extrapolations of past events. The net result is that many companies caught up in the BI hype have been quite disappointed in the return on their investment. To put it bluntly, BI with no predictive analytic capabilites to help organizations achieve high performance capabilities is pretty much useless.

In a series of studies conducted by Accenture, Jeanne Harris proposes a five-step model called DELTA  - data, enterprise, leadership, targets and analysts.

DATA - no two companies have exactly the same data even though they may be in the same industry. Mine the data to find what is unique about your company. Use the uniqueness to gain an analytical edge. To succeed in analytics, start identifying the data that you alone possess and recognize the value in it.

ENTERPRISE - data cannot live in silos. Integration of data, processes and analyses in a large, geographically dispersed company is a challenge in itself. So, does it make sense to adopt a companywide perspective for analytics? It depends...especially if all departments in the corporation share markets. According to Harris answers to the following six questions help determine if a companywide approach to analytics will be helpful.
 
Source: Davenport, Harris, Morison. Analytics at Work: Smarter Decisions, Better Results. Boston. Harvard University Press, 2010

Bottom line -  a company that is committed to increasing customer satisfaction will ensure that its data does not reside in silos but is accessible with integrated analytics across the enterprise; the only exception being if data has to be "siloed" for legal reasons.

LEADERSHIP - a company needs analytical leaders - individuals with people skills and an analytical bent. People who know to ask the right questions and will not hesitate to push back when the team makes recommendations based on intuition and not based on hard empirical evidence. Leaders hire smart people, mentor and train them.

TARGETS - Analytics should be targeted at areas where the ROI is the highest and can be easily measured. Some examples are:
analytics that enable effective use of resource sharing;

• analytics that increase customer satisfaction;
• analytics that increase profitability;
• analytics that increase quality;
• analytics that identify dependencies and streamline processes.

ANALYSTS - we need analytical professionals who understand statistical models, probability theory, trend analysis, classification algorithms and simulation. These jobs tend to require an advanced degree in mathematics, statistics and in a quantitative field.

Adopting the DELTA model can go a long way in building a strong analytical capability. However an aggressive implementation of DELTA can also result in stagnation and paralysis if we don't stay away from the following traps. Do not over-fit the curve, says, Kishore Swaminathan, a Beijing-based analyst because there is no sense in analyzing additional data once a pattern has been found. It also does not make sense to wait for data that simply does not exist. Design models and experiments based on the data you have, not based on the data that you would like to have. Lastly, it is important to know the risk tolerance of your company. Do not wait to act unless there is enough data to guarantee a successful outcome.

Business Intelligence when used right will result in an enterprise that is able to make its decisions in a timely fashion based on observations produced by empirical analysis of data.

Lean Six Sigma in Software Development.

"Six Sigma" is a process man-agement strategy developed by Motorola in 1986 to improve the quality of products by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing outputs. "Lean" on the other hand is a production practice that aims to eliminate expenses for resources that are not creating value in the product.

How do we combine Lean and Software especially since Lean Six Sigma has had its origins in manufacturing and does not translate easily to software development? The Poppendiecks in their book titled "Implementing Lean Software development" successfully make a case that writing software is really a form of product development and hence the implementation of Lean Six Sigma in software development is possible. They claim that, software not devel-oped as a stand-alone product is usually embedded in hardware, or it may be part of a game, or a business process - which means that software is either a product or a subset of a product.

"The seven principles" of Lean Software Development are:

• Eliminate Waste
• Build Quality In
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimize the Whole

Eliminate Waste
Identify the 20% of product features that deliver 80% of value to the customer. Focus on implementing the 20% for deployment in the first phase.

Build Quality In
Develop QA standards and QC processes to catch defects early on in the software development life cycle. Test-driven design (TDD) is a very effective to reduce and eliminate defects.

Create Knowledge
Use feedback from daily builds and early release of the minimum 20% feature set to customers for evaluation and feedback.

Defer Commitment
Define the architecture model such that most decisions related to the feature set can be reversed and changed. A realistic design approach is to leave options open so that irreversible decisions can be made as late as possible.

Deliver Fast
Deliver software so quickly that customers don't have time to change their mind", say the Poppendiecks.

Respect People
Allow team members to offer feedback and ask questions. Just make sure you answer every question. You are not too busy and neither is any question unimportant that it does not deserver an answer. Employ team-building activities to help open the lines of communication and create co-dependence between members of the team.

Optimize the Whole
Lean software development needs the support of the entire organization. The entire value stream from the time a customer request comes in, to the time the software is delivered must be optimized.

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!