A new start...

Software Testing Classics : Bug Advocacy by Cem Kaner

noreply@blogger.com (Sharad) — Tue, 17 May 2011 08:44:00 +0000

What is “Bug Advocacy” all about?

The title pretty much says it all (I hope), but let’s take a look at some key excerpts from this 100-page masterpiece to find out more. First the, the premise:

The point of testing is to find bugs.
Bug reports are your primary work product. This is what people outside of the testing group will most notice and most remember of your work.
The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.
Programmers operate under time constraints and competing priorities. For example, outside of the 8-hour workday, some programmers prefer sleeping and watching Star Wars to fixing bugs.

A bug report is a tool that you use to sell the programmer on the idea of spending her time and energy to fix a bug.

Motivating the Bug Fixer
Some things that will often make programmers want to fix the bug:

It looks really bad.
It will affect lots of people.
Getting to it is trivially easy.
It has embarrassed the company, or a bug like it embarrassed a competitor.
One of its cousins embarrassed the company or a competitor.
Management (that is, someone with influence) has said that they really want it fixed.
You’ve said that you want the bug fixed, and the programmer likes you, trusts your judgment, is susceptible to flattery from you, owes you a favor or accepted bribes from you.

Overcoming Objections Via Analysis of the Failure

Things that will make programmers resist spending time on the bug:

The programmer can’t replicate the defect.
Strange and complex set of steps required to induce the failure.
Not enough information to know what steps are required, and it will take a lot of work to figure them out.
The programmer doesn’t understand the report.
Unrealistic (e.g. “corner case”)

~SA

Agile and Cloud - Made for Each Other

noreply@blogger.com (Sharad) — Tue, 19 Apr 2011 14:17:00 +0000

Agile and the Cloud: Perfect Together:

Agile is a style of software development that places new capabilities in the hands of users, as and when they need them—almost as rapidly as they need them. It does this by stripping the project requirements down into achievable component parts and then focusing on each part individually and single-mindedly, full of intent, energy, and drive. As each part is developed, it becomes an “iteration,” a release of useable software that can be made instantly available to users instantly. While they start using it, the development team moves onto the next step, the subsequent iteration. At every step of the way, product owners, developers, and users emphasize collaboration. Everything is transparent to the client and the users. And, one of the most valuable aspects of all is that no useless functionality is built for users.

Agile and cloud computing are actually highly parallel concepts, both in terms of their methods and their aims. Perhaps the best way of summing up the benefits of agile development methodologies is to examine the definition of the word itself: characterized by quickness, lightness, and ease of movement; deft and active. The cloud can catalyze the development process. It’s just like the atmosphere; it’s everywhere. This means that new applications can be made available to users instantly, the very second a development team has completed them. There is no need for drawn-out deployment procedures, patches, and reinstallations. Users can jump right in and start using. Integration issues are overcome, change management is addressed, and risks are minimized.

Putting agile together with the cloud dramatically accelerates an organization’s improvement pace. The working style of agile is tied up with user involvement, drawing users right into the heart of the development process. Functionality is developed as the user wants it, how he wants it. As developments move along in cumulative steps (iterations), the features and benefits can be rationalized and reprioritized as each project unfolds. There is no waste—either of time or money. And just as soon as everyone agrees that the application is ready, off it goes into the cloud where everyone can start using it.

Agile development in the cloud now gives greater control over process innovation and more strength to a company’s competitive edge than ever before, and organizations in every vertical market now have exciting prospects.

Scrum Rules

noreply@blogger.com (Sharad) — Tue, 30 Nov 2010 08:10:00 +0000

Here is the list of the "Rules" which any agile(Scrum) team needs to follow. These rules are categorized into Required Rules, Basic Rules and Optional Rules.

Required Rules to Start – the “Agile Skeleton”:

Full-Time ScrumMaster Identified and Team Members Available to Do Work
Team Agrees to Demonstrate Working Software in No More Than 30 Days
Stakeholders Invited to Demonstration

Basic Rules of Scrum to Implement As Soon As Possible:

ScrumMaster Ensures “Required” and “Basic” Rules Followed
Full-Time Product Owner (with Expertise and Authority) Identified
Cross-Functional Team Including ScrumMaster and Product Owner
Team Size 7 +/-2, Maximum of 12
Product Owner Works With Team and All Other Stakeholders
Product Backlog Created and Managed by Product Owner
Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
Daily Scrum at Same Place and Time and Less Than 15 Minutes
All Team Members Required at Daily Scrum
Anyone Can Observe Daily Scrum, but Not Participate
Sprint Length No More Than 30 Days, and Consistently Same Length
Sprint Planning Meeting with Whole Team
First Part of Sprint Planning: Product Backlog Items Selected by Team
Second Part of Sprint Planning: Team Creates Sprint Backlog of Estimated Tasks
Sprint Backlog Tasks Added/Updated/Removed by Team
Sprint Burndown Chart
Retrospective Meeting with Whole Team for Process Improvements
Definition of “Done”
Commitment Velocity Calculated (from Sprint Backlog Estimates)
Team Members Volunteer for Tasks, 1 Task at a Time Until Complete
Team can Seek Advice, Help, Info
ScrumMaster Tracking and Removing Obstacles
No Interruptions, Advice about or Reprioritization of Team's Work During Sprints
No “Break” Between Sprints
Sustainable Pace – Timebox Effort, Not Just Schedule
Quality is Not Negotiable – Defects Go on Top of Product Backlog
Sprint Planning and Review Meetings 1/20th Sprint Duration

Optional Rules of Scrum to Implement Depending on Context:

Team Room with All Needed Equipment and Supplies
Test Driven Work and Continuous Integration
User Stories as Product Backlog Items (As a I can so that )
Project/Release Burndown Chart
Planning Velocity Calculated (from Product Backlog Estimates)
Scrum of Scrums for Multiple Teams
Canceling the Sprint Early
Financial Modeling for Product Backlog
Sprint Backlog Tasks on Big Visible Chart on Wall
Backup Product Owner Identified
Team of Volunteers – Self-Selecting
Rotate the ScrumMaster Duties

~SA

Affinity Estimating - A Better Way of Estimating User Stories in Agile

noreply@blogger.com (Sharad) — Thu, 28 Oct 2010 09:19:00 +0000

Affinity Estimating by Lowell Lindstrom:

Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of user stories. This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet.

In this technique stories are read out to the whole team and then the team is asked to arrange the stories on horizontally on a wall in order of size, without talking.
Place the largest stories on the left and the smallest stories on the right. This only takes a few minutes. Then you get a final opportunity to make adjustments to the ordering, again without talking.
Place some Fibonacci numbers (described by Mike Cohn in “Agile Estimating and Planning“) above the list of stories. Then group the user stories around the nearest number.
By using this technique, a team can estimate good number of User Stories only in a few minutes.

In agile many teams use "Planning Poker" a widely prevalent technique to estimate, which is a consensus based, but this way of estimating take too much time. Where Affinity estimating technique is very quick & transparent.

In Kane Mar words: I loved this (Affinity) estimating technique for a number of reasons: It’s quick and easy; it feels very natural; and, the entire decision making process is made very visible. Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one.

~SA

Agile Modeling

noreply@blogger.com (Sharad) — Thu, 30 Sep 2010 07:22:00 +0000

Agile Modeling (AM) is a practice-based methodology for effective modeling of software-based systems. Where the Unified Modeling Language (UML) defines a subset of the modeling techniques that software professionals require, AM defines practices that enables developers to model in an efficient and effective manner. This paper provides a brief overview of AM’s values, principles,
and practices; defined what agile models are; and summarizes the scope of AM.

When is a Model Agile?
To understand AM you need to understand the difference between a model and an agile model. A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem. Traditionally, models are thought of as zero or more diagrams plus any corresponding documentation. However non-visual artifacts such collections of CRC cards, a textual description of one or more business rules, or the structured English description of a business process are also considered to be models. An agile model is a model that is just barely good enough. But how do you know when a model is good enough? Agile models are good enough when they exhibit the following traits:
(1) They fulfill their purpose and no more.
(2) They are understandable.
(3) They are sufficiently accurate.
(4) They are sufficiently consistent.
(5) They are sufficiently detailed.
(6) They provide positive value.
(7) They are as simple as possible.

What Is(n’t) Agile Modeling?
I am a firm believer that when you are describing the scope of something, be it a system or in the case of AM a methodology, that you should describe both what it is and what it isn’t. The following points describe the scope of AM:
(1) AM is an attitude, not a prescriptive process.
(2) AM is a supplement to existing methods, it is not a complete software development methodology.
(3) AM is a way to work together effectively to meet the needs of project stakeholders.
(4) AM is effective and is about being effective.
(5) AM is something that works in practice, it isn’t an academic theory.
(6) AM is not a silver bullet.
(7) AM is for the average developer, but is not a replacement for competent people.
(8) AM is not an attack on documentation.
(9) AM is not an attack on CASE tools.
(10)AM is not for everyone.
(11)AM is complementary to the UML.

Ta,
~SA

Difference Between Agile Themes, Epics and User Stories

noreply@blogger.com (Sharad) — Wed, 11 Aug 2010 05:50:00 +0000

People often get confused about the difference between Agile Themes, Epics and User Stories.

Here’s a simple explanation of what they are and and a diagram showing how they relate to one another.

Agile Themes

A Theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific. At its most granular form, a Theme may be an Epic.

Themes can be used at both Programme and Project Level to drive strategic alignment and communicate a clear direction.

Agile Epics

An Agile Epic is a group of related User Stories. You would be unlikely to introduce an Epic into a sprint without first breaking it down into it’s component User Stories so to reduce uncertainty.

Epics can also be used at a both Programme and Project Level – Read more using Epic Boards to manage programmes and projects.

Agile User Stories

A User story is an Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (“INVEST Acronym”). Despite being Independent i.e. they have no direct dependencies with another requirements, User stories may be clustered into Epics when represented on a Product Roadmap.

User Stories are great for Development Teams and Product Managers as they are easy to understand, discuss and prioritise – they are more commonly used at Sprint-level. User Stories will often be broken down into Tasks during the Sprint Planning Process – that is unless the stories are small enough to consume on their own.

The Hierarchy of Agile Requirement Formats - Themes, Epics, User Stories, Tasks

Scrum Master vs Product Owner

noreply@blogger.com (Sharad) — Mon, 19 Jul 2010 12:16:00 +0000

The most common confusion in the 2 roles of Agile-SCRUM is between Scrum Master & Product Owner.

The Scrum Master is in charge of making sure the Scrum process is followed. The Product Owner (PO) is the person in charge of making sure the product succeeds in the direction the company wants to go.

The PO does this by setting priorities of product backlog items, making sure all needed parties are there for both the sprint planning and sprint review (both are very important). If something occurs and either the scope explodes or decisions need to be made, the PO is the person who gives the answers to the decisions (whether they are the person making the decision or not). I like to think of the product owner as the prioritizer and proxy between IT and the business/customer. Although another common term for that person is "single wringable neck" because if the company isn't succeeding with that product, it's probably a prioritization issue...and who is in charge of that :-).

The Scrum Master is making sure the process gets followed and working through the adaptation of Scrum to your organization. By doing this, they help to create a high performance team or teams. There are many "styles" to achieving this, but the goal is the same.

Ta,
~SA

Metrics Used In Testing

noreply@blogger.com (Sharad) — Mon, 21 Jun 2010 12:17:00 +0000

Metrics Used In Testing:

The Product Quality Measures -
1. Customer satisfaction index,
2. Delivered defect quantities,
3. Responsiveness (turnaround time) to users,
4. Product volatility,
5. Defect ratios,
6. Defect removal efficiency,
7. Complexity of delivered product,
8. Test coverage,
9. Cost of defects,
10. Costs of quality activities,
11. Re-work,
12. Reliability and Metrics for Evaluating Application System Testing.

1. Customer satisfaction index

This index is surveyed before product delivery and after product delivery (and on-going on a periodic basis, using standard questionnaires).The following are analyzed:

* Number of system enhancement requests per year
* Number of maintenance fix requests per year
* User friendliness: call volume to customer service hotline
* User friendliness: training time per new user
* Number of product recalls or fix releases (software vendors)
* Number of production re-runs (in-house information systems groups)

2. Delivered defect quantities

They are normalized per function point (or per LOC) at product delivery (first 3 months or first year of operation) or Ongoing (per year of operation) by level of severity, by category or cause, e.g.: requirements defect, design defect, code defect, documentation/on-line help defect, defect introduced by fixes, etc.

3. Responsiveness (turnaround time) to users

* Turnaround time for defect fixes, by level of severity
* Time for minor vs. major enhancements; actual vs. planned elapsed time

4. Product volatility

* Ratio of maintenance fixes (to repair the system & bring it into compliance with specifications), vs. enhancement requests (requests by users to enhance or change functionality)

5. Defect ratios

* Defects found after product delivery per function point.
* Defects found after product delivery per LOC
* Pre-delivery defects: annual post-delivery defects
* Defects per function point of the system modifications

6. Defect removal efficiency

* Number of post-release defects (found by clients in field operation), categorized by level of severity
* Ratio of defects found internally prior to release (via inspections and testing), as a percentage of all defects
* All defects include defects found internally plus externally (by customers) in the first year after product delivery

7. Complexity of delivered product

* McCabe's cyclomatic complexity counts across the system
* Halstead’s measure
* Card's design complexity measures
* Predicted defects and maintenance costs, based on complexity measures

8. Test coverage

* Breadth of functional coverage
* Percentage of paths, branches or conditions that were actually tested
* Percentage by criticality level: perceived level of risk of paths
* The ratio of the number of detected faults to the number of predicted faults.

9. Cost of defects

* Business losses per defect that occurs during operation
* Business interruption costs; costs of work-arounds
* Lost sales and lost goodwill
* Litigation costs resulting from defects
* Annual maintenance cost (per function point)
* Annual operating cost (per function point)
* Measurable damage to your boss's career

10. Costs of quality activities

* Costs of reviews, inspections and preventive measures
* Costs of test planning and preparation
* Costs of test execution, defect tracking, version and change control
* Costs of diagnostics, debugging and fixing
* Costs of tools and tool support
* Costs of test case library maintenance
* Costs of testing & QA education associated with the product
* Costs of monitoring and oversight by the QA organization (if separate from the development and test organizations)

11. Re-work

* Re-work effort (hours, as a percentage of the original coding hours)
* Re-worked LOC (source lines of code, as a percentage of the total delivered LOC)
* Re-worked software components (as a percentage of the total delivered components)

12. Reliability

* Availability (percentage of time a system is available, versus the time the system is needed to be available)
* Mean time between failure (MTBF).
* Man time to repair (MTTR)
* Reliability ratio (MTBF / MTTR)
* Number of product recalls or fix releases
* Number of production re-runs as a ratio of production runs

Metrics for Evaluating Application System Testing:

Metric = Formula

Test Coverage = Number of units (KLOC/FP) tested / total size of the system. (LOC represents Lines of Code)

Number of tests per unit size = Number of test cases per KLOC/FP (LOC represents Lines of Code).

Acceptance criteria tested = Acceptance criteria tested / total acceptance criteria

Defects per size = Defects detected / system size

Test cost (in %) = Cost of testing / total cost *100

Cost to locate defect = Cost of testing / the number of defects located

Achieving Budget = Actual cost of testing / Budgeted cost of testing

Defects detected in testing = Defects detected in testing / total system defects

Defects detected in production = Defects detected in production/system size

Quality of Testing = No of defects found during Testing/(No of defects found during testing + No of acceptance defects found after delivery) *100

Effectiveness of testing to business = Loss due to problems / total resources processed by the system.

System complaints = Number of third party complaints / number of transactions processed

Scale of Ten = Assessment of testing by giving rating in scale of 1 to 10

Source Code Analysis = Number of source code statements changed / total number of tests.

Effort Productivity = Test Planning Productivity = No of Test cases designed / Actual Effort for Design and Documentation

Test Execution Productivity = No of Test cycles executed / Actual Effort for testing

QA dilemmas in Agile environment

noreply@blogger.com (Sharad) — Wed, 26 May 2010 08:07:00 +0000

I have heard many times that practicing agile raises some dilemmas when trying to keep the QA standards.
There are few examples mentioned below:

1. Little documentation and lots of changes that are imposed with direct verbal discussion between product manager and developers, makes it hard for QA to write their test documents and keep them updated.

2. The "Team" needs to deliver product in time , yet lots of tasks are completed simultaneously at the last moment. Little consideration for the amount of time QA needs to give a green light. At this stage QA are alone and "Team" is busy with future tasks.

By reading above points, first thing comes in my mind is that it is an execution of a waterfall project disguised as agile. A number of things stood out that are not in alignment with an agile project:

• Little documentation- Agile does not mandate little documentation. It says use the type and amount of documentation you need, but no more. If the documents to which you are referring are critical to the completion of the iteration then the time necessary needs to be accounted for in your iteration planning. The idea though is that documents should be used to capture the results of a discussion, but the discussion is where the team does most of their learning and uses the documents as a reference when necessary. The team should ask themselves what value the documents are adding and are they worth the time they take. Can the detail in the document be reduced? One of the things a team I am working with discovered was their test cases were WAY too detailed. They contained every single step a tester needed to go through for each test case. When they asked the testers why they needed to detail every step for a system they all knew very well they said “we don’t need this detail, we are only doing it because our process said we had to”. The test cases were shrunk to about 20% of their normal size.
• Last point makes brings up a number of items that sound very waterfall like:
o QA left alone and “Team” is busy with future tasks – There is one team on an agile project. Until the iteration is done no one on the team should be working on future tasks. One of the main focuses of agile projects is to get one thing completely done before moving on to the next. What you described sounds like a classic waterfall approach. Why aren’t the other members of the team assisting with the testing to complete the iteration?
o Tasks are completed at the last moment – agile projects are feature focused rather than task focused. If everything being developed is not being tested until the end of the iteration then you are following a sequential process and it will be highly unlikely you will realize the benefits associated with agile. You ideally want to be doing testing on features throughout the entire iteration. This requires planning and good selection of items from the backlog to ensure that you will have flow of feature completion throughout the iteration.
o QA giving the green light – Why is QA giving the green light? There should be a definition of done that defines the criteria of a backlog item being done. The definition of done should be used during the planning to make sure the tasks necessary to cover all the criteria are accounted for.
• Getting teams to work in unison rather than in a sequential manner is hard, but it is critical to achieving the benefits of an agile approach.

~SA

User Stories Vs. Tasks

noreply@blogger.com (Sharad) — Thu, 22 Apr 2010 06:34:00 +0000

User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

A Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.

Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.

In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.

Writing stories should be a separate activity from the tasking of the stories themselves. The story should be about what specifically you want your product to do and clearly explain the value of this feature. Together with the scrum team you should clearly define the acceptance criteria of the story. Only after these are defined should the story be tasked out by the contributors who will be doing the work. They get to decide how to best get it done.

The process of breaking down a user story is important because it helps me think about how I'm going to build the functionality. Many people disaggregate a user story into tasks and then estimate them (usually in ideal time) because they're smaller units of work and can be estimated with less inaccuracy. Then they total the task estimates to obtain a better indication of how long it will take to complete the user story. Tracking each task's remaining time feels like micro-management, so I don't it anymore. I'm only interested in tracking the number of running tested features. I want to know how many user stories are passing all their FIT tests.

~SA

Agile estimation – Story Points vs. Hours

noreply@blogger.com (Sharad) — Tue, 13 Apr 2010 06:34:00 +0000

The most common debate (or rather, amusement) between software engineers in an agile team - hours (or days) and not story points are a better way to estimate user stories. I disagree.

Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.

Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.

Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.

Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
where
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge

Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.

On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.

Finally, if I hear someone say that they have a capacity of 200 real hours, that they’re signing up for 300 hours of work and end up completing 250, then in my mind, the 250 hours of work that got done (which can’t be squeezed into 200 real hours) might as well be 250 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 200 real hours (time doesn’t change), they signed up for 3000 points and got 2500 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…

~SA

Instant Gratification To My Dear Pa

noreply@blogger.com (Sharad) — Tue, 06 Apr 2010 12:13:00 +0000

It's true what everyone says. When you lose someone who was so close to you, and so involved in your life, the pain never really goes away. I lost my father last month, and I still feel like he is on a perpetual vacation. He was very nice person, not an alcoholic, was not abusive, and was not a bad father. He was actually the best father he could have been. He loved me so much & i loved him too.

There is not a day that I do not think of him or wonder what he might think of me if he were still here; but by taking the best of his qualities and learning lessons from his life, I like to think that I have kept the flame of his spirit dancing within the halls of my own being. In that sense, he has never left, and he will continue to accompany me during the remainder of my own limited time on this planet.

Thanks Pa for giving me life & everything in this life. I'll miss you always.

Business Process Interoperability (BPI) & Business Process Testing (BPT)

noreply@blogger.com (Sharad) — Tue, 23 Feb 2010 08:12:00 +0000

BUSINESS PROCESS INTEROPERABILITY (BPI):

Business process interoperability (BPI) is a property referring to the ability of diverse business processes to work together, to so called "inter-operate".

It is a state that exists when a business process can meet a specific objective automatically utilizing essential human labor only. Typically, BPI is present when a process conforms to standards that enable it to achieve its objective regardless of ownership, location, make, version or design of the computer systems used.

BUSINESS PROCESS TESTING (BPT):

The testing of the full business process, from the start of a transaction (which might be a telephone call) through to the completion (which might be the receipt of payment for an invoice after goods have been shipped).

Testing the full business process ensures that the system is really going to work. There are many examples of excellent software systems being implemented, where the supporting processes don’t work and undermine the effectiveness of the software (for example, e-commerce sites work perfectly, but the delivery companies don’t deliver when expected and ruin the customer experience).

Where the implementation of the system requires a lot of interaction between the business and the system(s) then a dress rehearsal is highly recommended.

~SA

Agile Testing Book

noreply@blogger.com (Sharad) — Fri, 29 Jan 2010 09:30:00 +0000

Agile Testing: A Practical Guide for Testers and Agile Teams, one of the best book by agile testing gurus Lisa Crispin and Janet Gregory. If you are interested to know about the Agile testing, this is a "must read" book.

~SA

A New Start for a New Year

noreply@blogger.com (Sharad) — Thu, 31 Dec 2009 09:47:00 +0000

I don’t really bother with new year resolutions, but it is a good time to take stock and make a new start for the new year. Most of us are feeling the effects of the recession, so rather than moaning about our finances this is a good time to take action.

Take Control of Your Food Shopping:
By planning your shopping in advance and buying the supermarket own brand products where possible you can avoid waste and cut your grocery bills significantly.

Take Control of Your Car Costs:
The cost of running your car makes a significant dent in your weekly budget, but a few simple adjustments will help you to reduce the cost of fuel for your car. Good planning and sensible driving can help you to reduce unnecessary journeys and avoid wasting fuel.

Give Your Time To Your Family:
In the long term your children will not remember the expensive gifts that you worked so hard to provide. They will remember time spent with you doing simple things like cooking, playing in the park or going to the library. Your family need your time and attention, family time doesn’t have to be expensive there are lots of things that you can do as a family that cost very little.

Be Content With What You Have:
In recent years we have got used to spending more than we have and always being able to have what we wanted when we wanted it. Our grandparents and great grandparents lived their lives very differently and there is a lot we can learn from their example. Like them we must learn to live within our means, to take care of the things we have and not waste anything. It will help us, but it will also help the planet if we learn to live more sustainably.

Don’t Be Too Proud to Accept Advice:
Don’t overlook the wisdom of those who have lived a little longer than you, you may have heard it all before but take a little time to consider their advice. Your Grandmother’s sayings may have taken their place in family folk law, but remember that her generation lived through the hardest of times, so there may be a lot that you can learn from her example of independence and determination.

Finally, Wish You A Happy & Prosperous New Year 2010 to all of you!!!

With Love,
~SA

Zero Defects - Get it right first time

noreply@blogger.com (Sharad) — Mon, 09 Nov 2009 14:00:00 +0000

How much do quality failures cost your company?

Quality defects have significant costs associated with them - some of the most obvious being money, time, resources, and lost reputation. And programs to eliminate quality defects can be expensive and time consuming. Do you insist on eliminating defects entirely no matter the cost? Or, do you accept that a certain, albeit very small, percentage of defects is acceptable, and just accept the costs and learn to live with them?

One of the most influential ideas about this was the notion of "zero defects." This phrase was coined by Philip Crosby in his 1979 book titled, "Quality is Free."

His position was that where there are zero defects, there are no costs associated with issues of poor quality; and hence, quality becomes free.
Explaining the Idea

Zero defects is a way of thinking and doing that reinforces the notion that defects are not acceptable, and that everyone should "do things right the first time". The idea here is that with a philosophy of zero defects, you can increase profits both by eliminating the cost of failure and increasing revenues through increased customer satisfaction.

***"While this will probably be true, it may not be true in every case!"

"Zero defects" is referred to as a philosophy, a mentality or a movement. It's not a program, nor does it have distinct steps to follow or rules to abide by. This is perhaps why zero defects can be so effective, because it means it's adaptable to any situation, business, profession or industry.

The question that often comes up when zero defects is discussed, is whether or not zero defects is ever attainable. Essentially, does adopting a zero defect environment only set users up for failure?

Zero defects is NOT about being perfect. Zero defects is about changing your perspective. It does this by demanding that you:

* Recognize the high cost of quality issues;
* Continuously think of the places where flaws may be introduced; and
* Work proactively to address the flaws in your systems and processes, which allow defects to occur.

Zero defects is a standard. It is a measure against which any system, process, action, or outcome can be analyzed. When zero defects is the goal, every aspect of the business is subject to scrutiny in terms of whether it measures up.

***"The quality manager must be clear, right from the start, that zero defects is not a motivation program. Its purpose is to communicate to all employees the literal meaning of the words 'zero defects' and the thought that everyone should do things right the first time."

When you think about it, we expect zero defects when we are talking about items or services that we use. If you buy a fancy new plasma TV and your pixels start burning by the thousands, you demand satisfaction. When you take the car in for brake service, you expect that the mechanic will install the parts exactly as the manufacturer prescribes. No defect is an acceptable defect when it affects you personally.

So why then, is it so easy to accept that "defects happen" when you are the one producing the product or providing the service? This is the interesting dichotomy that presents itself. Zero defects is one of the best ways to resolve the discord between what we expect for ourselves and what we can accept for others.

***"Be very careful about where you apply zero defects. If what you're doing contributes towards a mission critical or complex goal, you'd better adopt a zero defects approach, or things could quickly unravel."

However, if you fanatically follow a zero defects approach in areas which don't need it, you'll most likely be wasting resources. One of the most important of these resources is time, and this is where people are accused of time-destroying "perfectionism."
Adopting Zero Defects

There are no step-by-step instructions for achieving zero defects, and there is no magic combination of elements that will result in them. There are, however, some guidelines and techniques to use when you decide you are ready to embrace the zero defects concept.

Management must commit to zero defects. Zero defects requires a top down approach: The best-intentioned employees cannot provide zero defects if they are not given the tools to do so.

* When you decide that zero defects is the approach you want to take, recognize that it likely represents a significant change to the way people do things. Manage the introduction using the principles of change management.

* Understand what your customers expect in terms of quality. Design systems that support zero defects where it matters, but don't over-design if the end-user just doesn't care.

* Zero defects requires a proactive approach. If you wait for flaws to emerge you are too late.

* Create quality improvement teams. Zero defects must be integrated with the corporate culture. Zero defects needs to be accepted as "the ways things are done around here".

* Learn poka - yoke (POH-kay YOH-kay.) Invented in the 1960s by Shigeo Shingo of Japan, it translates to "prevent inadvertent mistakes". It's an approach that emphasizes designing systems that make defects almost impossible or, if they can't be avoided, easy to detect and address. To implement zero defects, you have to have strong systems in place.

* Monitor your progress. Build mechanisms into your systems and methods of operating that provide continuous feedback. This allows you act quickly when flaws do occur.

* Measure your quality efforts. It is important to express your progress in terms of the bottom line. Take baseline measurements so you understand the cost of defects in your organization, and can measure the benefits your achieveing in eliminating them.

* Build quality into your performance expectations. Encourage members of your team to think about how they can achieve zero defects, and reward them when they're successful.

* Recognize that although zero defects is a destination, circumstances keep changing. Monitor, evaluate, and adapt in a continuous, never-ending cycle.

***"Things have moved on since 1979. Since then, there have been several waves of quality improvement which have taken things further, most recently resulting in "Six Sigma".

While zero defects is a useful idea, be aware that you may have to go much further nowadays if you want to lead your market in terms of quality of delivery."

Software Engineering Process Group (SEPG)

noreply@blogger.com (Sharad) — Mon, 12 Oct 2009 08:50:00 +0000

A Software Engineering Process Group (SEPG) is an organization's focal point for software process improvement activities. These individuals perform assessments of organizational capability, develop plans to implement needed improvements, coordinate the implementation of those plans, and measure the effectiveness of these efforts. Successful SEPGs require specialized skills and knowledge of many areas outside traditional software engineering.

Most organizations have many different projects or contracts underway simultaneously, and perhaps several different software development and maintenance divisions. Thus, many instances of the process improvement cycle may be operating concurrently. For example, one part of the organization may be following up on assessment findings by examining current cost-estimation practice, and another may be training software engineers in code inspections. The process improvement cycle works both globally across the organization, through policy changes and process assessments, and locally, with the implementation of particular changes. Assessments lead to strategy and policy updates; these updates lead to plans for the incorporation of new approaches to management and new software technology; the results meanwhile must be tracked and reported.

The software engineering process group is a central force for process improvement. The group maintains the overall view of current efforts and facilitates these efforts on a continuing basis. Its members foster collaboration among everyone in the organization who is involved with software process improvement.

Following are ongoing activities of the process group:

* Obtains and maintains the support of all levels of management.
* Facilitates software process assessments.
* Works with line managers whose projects are affected by changes in software engineering practice, providing a broad perspective of the improvement effort and helping them set expectations.
* Maintains collaborative working relationships with software engineers, especially to obtain, plan for, and install new practices and technologies.
* Arranges for any training or continuing education related to process improvements.
* Tracks, monitors, and reports on the status of particular improvement efforts.
* Facilitates the creation and maintenance of process definitions, in collaboration with managers and engineering staff.
* Maintains a process database.
* Provides process consultation to development projects and management.

The process group is not part of product development but is staffed by practitioners. As a result, it has expertise in software engineering. It may also have, and at any rate should develop, expertise in process definition, organizational change, and technology related to improving or measuring quality.

Costs & Benefits:
Process groups had to present a persuasive business case to become chartered and operational. Software
engineer process improvement was a concept with inherent merit in their organizations; competitive pressures required a steady increase in quality, which in turn required a commitment to improve. Nonetheless, it should be helpful to look briefly at specific costs and benefits of process groups and related efforts.

Costs:
The costs of estabilishing the software engineering process group and related functions- the process improvement infrastructure- are primarily labor costs. These are consumed in staff for the software engineering process group, and in the time spent in planning and implementing improvement actions. Often these are costs that would be expended on similar activities in any case, but in a less organized and therefore less visible way.

Benefits:
The primary benefit of an improved- that is, more disciplined -software process is improved visibility of the process. The visibilty makes the process more manageable during software development and maintenance, thus reducing risk. Schedules become more predictable, as do costs. Software is of higher quality at delivery and is easier to maintain. The cost of investment in process improvement work is amortized and ultimately more than rapid.

Another benefit is the improved prospect of winning and keeping contracts when the government includes software process maturity in its source selection and contract management criteria. Moreover, if certain contracts incentives are inaugurated, developers would be paid an award fee of up to 15% based on software quality as assessed during the early post -deployment phase. A mature development process would make it more likely that the award would be earned.

With Love,
~SA

Quality Assurance Process Tasks

noreply@blogger.com (Sharad) — Thu, 17 Sep 2009 06:10:00 +0000

PROCESS TASKS:

1. Establish QA organization or function

The PM appoints an individual or group responsible for QA. QA must have organizational freedom, authority, and independence to objectively evaluate and report on project activities. The QA Group maintains a reporting channel to senior management that is independent of the project.

2. Select QA tasks and assign responsibilities

The QA Group defines and assigns the tasks, work products and processes that will be performed, such as those listed below:

a. Review products, tools, services, and facilities against requirements, standards and guidelines.

b. Audit project processes for compliance with standards, and established best practices.

c. Participate in peer reviews and project reviews (technical and management reviews) by providing status on compliance, problem areas, and risks.

d. Suggest methods, standards, guidelines, and tools to be defined for the project and verify they are documented in the project management plan or separate QA plan.

e. Report results of product and/or service evaluations and process audits to the PM, senior management, relevant stakeholders, and the project’s engineering process group (e.g. SEPG) as appropriate.

f. Collect and report metrics on the status of cost and schedule, product evaluations, project quality, and audits.

g. Collect improvement information on the QA processes and establish and maintain a description of the defined process.

3. Establish and maintain the plan for the QA Process
The QA Group develops and documents QA plans in the project plan or equivalently in a QA Plan. Depending on the size and type of QA activities required, planning topics can include those listed below:

· Quality objectives, in measurable terms

· Types of test and verification and validation (V&V) activities

· Entry and exit criteria for project lifecycle phases

· Responsibilities of the QA group

· Resource and training requirements for the QA group or function

· Scheduling, budgeting and funding of QA activities

· QA participation in development of project plans, standards, and procedures

· Process evaluations and audits to be performed by QA

· Product and service audits and reviews to be conducted by QA

· Standards and procedures used for QA

· Documenting and tracking noncompliance issues, and the escalation procedure

· Documentation that QA establishes, maintains, and controls over the life of the project through delivery

· Method, audience, and frequency of providing feedback on QA activities

4. Create and maintain QA procedures and checklists
The QA Group establishes and maintains the procedures, checklists, and work aids that describe how QA is to be performed.

5. Resource and perform QA as described in the Plan

The QA Group ensures that resources (tools, databases, work stations, etc.,) for performing the QA Process, developing the work products and providing QA services are adequate. Tools required to perform the QA tasks are identified based on project requirements.

The QA Group performs the tasks as defined in the project or QA Plan. Problems or non-conformances with requirements and standards are documented and reported to the PM or appropriate authority. The QA Group communicates the results of QA activities to relevant stakeholders for resolution. Senior management addresses non-compliance issues that cannot be resolved within the project.

6. Identify and select QA training

The QA Group identifies training required to perform the tasks identified in the QA Plan. Training includes training of the QA Group and QA orientation for the project team members.

7. Monitor and control the QA Process

The QA Group monitors and controls the day-to-day QA activities against the QA Plan, schedule and budget. Identify and evaluate the effects of risks on, and significant deviations from, the QA plan, schedule and budget. Take corrective action when requirements and objectives are not being satisfied or when progress differs significantly from the plan.

8. Place QA work products under CM

The QA Group places completed QA work products under configuration management (CM) in accordance with the project CM Plan.

9. Objectively evaluate the QA Process

The Objective Verifier evaluates the QA Group to provide credible assurance that the QA Process is implemented as planned, and adheres to its process description, standards and procedures.

10. Review QA activities and results with senior management and stakeholders

QA activities, status and results are reviewed with the stakeholders, PM and senior management on a periodic and event-driven basis as designated in the QA Plan. The QA Group escalates unresolved or non-compliance issues and resolves them as necessary.

11. Collect improvement information

The QA Group initially reviews project QA processes and identifies improvements and efficiencies for future use. Suggestions for improvement of project QA processes are submitted to the project’s engineering project office for evaluation. Nominations for organizational standard best practices should be handled per the SSC San Diego SPA document, (submitted to SEPO, using Document Change Requests).

SEPO collects work products, measures, measurement results and improvement information derived from planning and performing the project QA Process to support future use and improvement as process assets.

SEPO establishes, collects and analyzes qualitative and quantitative measures of process variability to determine whether the processes are adequate for the intended function, satisfy project and organizational goals, and whether learning has been effectively shared.

12. Create and maintain a defined QA Process description

Working from SPI Agent and project nominations, SEPO and SPI Agents select and further refine QA best practice nominations into defined organizational QA standard process descriptions, templates and checklists for reuse as organizational process assets.

The QA Group then selects and tailors the QA Process assets from the process asset library according to the tailoring/scalability guidelines and the projects needs.

~SA

Agile Methodology

noreply@blogger.com (Sharad) — Fri, 07 Aug 2009 10:28:00 +0000

What Is Agile?

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, it’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.
Where Did Agile Come From?

In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.

It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?

Why Agile?

Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.

Agile Methods

Some of the well-known agile software development methods:

* Agile Modeling
* Agile Unified Process (AUP)
* Agile Data Method
* DSDM
* Essential Unified Process (EssUP)
* Extreme programming (XP)
* Feature Driven Development (FDD)
* Getting Real
* Open Unified Process (OpenUP)
* Scrum
* Lean software development

Agile Practices

* Test Driven Development (TDD)
* Behavior Driven Development (BDD)
* Continuous Integration
* Pair Programming
* Planning poker

Regards,
~SA

ISO (International Organization for Standardization)

noreply@blogger.com (Sharad) — Thu, 16 Jul 2009 07:42:00 +0000

About ISO

ISO (International Organization for Standardization) is the world's largest developer and publisher of International Standards.

ISO is a network of the national standards institutes of 161 countries, one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system.

ISO is a non-governmental organization that forms a bridge between the public and private sectors. On the one hand, many of its member institutes are part of the governmental structure of their countries, or are mandated by their government. On the other hand, other members have their roots uniquely in the private sector, having been set up by national partnerships of industry associations.

Therefore, ISO enables a consensus to be reached on solutions that meet both the requirements of business and the broader needs of society.

Discover ISO:

ISO's Name:

Because "International Organization for Standardization" would have different acronyms in different languages ("IOS" in English, "OIN" in French for Organisation internationale de normalisation), its founders decided to give it also a short, all-purpose name. They chose "ISO", derived from the Greek isos, meaning "equal". Whatever the country, whatever the language, the short form of the organization's name is always ISO.

Why standards matter:

Standards make an enormous and positive contribution to most aspects of our lives.

Standards ensure desirable characteristics of products and services such as quality, environmental friendliness, safety, reliability, efficiency and interchangeability - and at an economical cost.

When products and services meet our expectations, we tend to take this for granted and be unaware of the role of standards. However, when standards are absent, we soon notice. We soon care when products turn out to be of poor quality, do not fit, are incompatible with equipment that we already have, are unreliable or dangerous.

When products, systems, machinery and devices work well and safely, it is often because they meet standards. And the organization responsible for many thousands of the standards which benefit the world is ISO.

When standards are absent, we soon notice.

What standards do:

ISO standards:

make the development, manufacturing and supply of products and services more efficient, safer and cleaner
facilitate trade between countries and make it fairer
provide governments with a technical base for health, safety and environmental legislation, and conformity assessment
share technological advances and good management practice
disseminate innovation
safeguard consumers, and users in general, of products and services
make life simpler by providing solutions to common problems

Who standards benefit:

ISO standards provide technological, economic and societal benefits.

For businesses, the widespread adoption of International Standards means that suppliers can develop and offer products and services meeting specifications that have wide international acceptance in their sectors. Therefore, businesses using International Standards can compete on many more markets around the world.

For innovators of new technologies, International Standards on aspects like terminology, compatibility and safety speed up the dissemination of innovations and their development into manufacturable and marketable products.

For customers, the worldwide compatibility of technology which is achieved when products and services are based on International Standards gives them a broad choice of offers. They also benefit from the effects of competition among suppliers.

For governments, International Standards provide the technological and scientific bases underpinning health, safety and environmental legislation.

For trade officials, International Standards create "a level playing field" for all competitors on those markets. The existence of divergent national or regional standards can create technical barriers to trade. International Standards are the technical means by which political trade agreements can be put into practice.

For developing countries, International Standards that represent an international consensus on the state of the art are an important source of technological know-how. By defining the characteristics that products and services will be expected to meet on export markets, International Standards give developing countries a basis for making the right decisions when investing their scarce resources and thus avoid squandering them.

For consumers, conformity of products and services to International Standards provides assurance about their quality, safety and reliability.

For everyone, International Standards contribute to the quality of life in general by ensuring that the transport, machinery and tools we use are safe.

For the planet we inhabit, International Standards on air, water and soil quality, on emissions of gases and radiation and environmental aspects of products can contribute to efforts to preserve the environment.

The ISO brand:

Democratic

Every full member of ISO has the right to take part in the development of any standard which it judges to be important to its country's economy. No matter what the size or strength of that economy, each participating member in ISO has one vote. Each country is on an equal footing to influence the direction of ISO's work at the strategic level, as well as the technical content of its individual standards.

Voluntary

ISO standards are voluntary. As a non-governmental organization, ISO has no legal authority to enforce the implementation of its standards. ISO does not regulate or legislate. However, countries may decide to adopt ISO standards - mainly those concerned with health, safety or the environment - as regulations or refer to them in legislation, for which they provide the technical basis. In addition, although ISO standards are voluntary, they may become a market requirement, as has happened in the case of ISO 9001 quality management systems, or of dimensions of freight containers and bank cards.

ISO itself does not regulate or legislate.

Market-driven

ISO only develops standards for which there is a market requirement. The work is mainly carried out by experts from the industrial, technical and business sectors which have asked for the standards, and which subsequently put them to use.

Consensus

ISO standards are based on international consensus among the experts in the field. Consensus, like technology, evolves and ISO takes account both of evolving technology and of evolving interests by requiring a periodic review of its standards at least every five years to decide whether they should be maintained, updated or withdrawn. In this way, ISO standards retain their position as the state of the art.

Globally relevant

ISO standards are technical agreements which provide the framework for compatible technology worldwide. They are designed to be globally relevant - useful everywhere in the world.

ISO standards are useful everywhere in the world.

How to recognize an ISO standard:

In paper form, an ISO standard is published in A4 format - which is itself one of the ISO standard paper sizes. It may be anywhere between a four-page document and one several hundred pages' long. ISO standards are also available as electronic downloads and many are available as part of a collection on CD or in handbook. An ISO standard carries the ISO logo and the designation, "International Standard".

The scope of ISO's work:

ISO has more than 17500 International Standards and other types of normative documents in its current portfolio. ISO's work programme ranges from standards for traditional activities, such as agriculture and construction, through mechanical engineering, manufacturing and distribution, to transport, medical devices, information and communication technologies, and to standards for good management practice and for services.

Examples of the benefits standards provide:

Standardization of screw threads helps to keep chairs, children's bicycles and aircraft together and solves the repair and maintenance problems caused by a lack of standardization that were once a major headache for manufacturers and product users.

Standards establishing an international consensus on terminology make technology transfer easier and safer. They are an important stage in the advancement of new technologies and dissemination of innovation.

Without the standardized dimensions of freight containers, international trade would be slower and more expensive.

Without the standardization of telephone and banking cards, life would be more complicated.

A lack of standardization may even affect the quality of life itself: for the disabled, for example, when they are barred access to consumer products, public transport and buildings because the dimensions of wheel-chairs and entrances are not standardized.

Standardized symbols provide danger warnings and information across linguistic frontiers.

Consensus on grades of various materials gives a common reference for suppliers and clients in business dealings.

Agreement on a sufficient number of variations of a product to meet most current applications allows economies of scale with cost benefits for both producers and consumers. An example is the standardization of paper sizes.

Standardization of performance or safety requirements of diverse equipment makes sure that users' needs are met while allowing individual manufacturers the freedom to design their own solution on how to meet those needs.

Standardized computer protocols allow products from different vendors to "talk" to each other.

Standardized documents speed up the transit of goods, or identify sensitive or dangerous cargoes that may be handled by people speaking different languages.

Standardization of connections and interfaces of all types ensures the compatibility of equipment of diverse origins and the interoperability of different technologies.

Agreement on test methods allows meaningful comparisons of products, or plays an important part in controlling pollution - whether by noise, vibration or emissions.

Safety standards for machinery protect people at work, at play, at sea... and at the dentist's.

Without the international agreement contained in ISO standards on metric quantities and units, shopping and trade would be haphazard, science would be unscientific and technological development would be handicapped.

~SA

CMM & CMMI

noreply@blogger.com (Sharad) — Tue, 30 Jun 2009 11:34:00 +0000

Capability Maturity Model (CMM):
The Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes. The CMM has been superseded by the Capability Maturity Model Integration (CMMI).

Capability Maturity Model structure

The Capability Maturity Model involves the following aspects:

* Maturity Levels: A 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.
* Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
* Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
* Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
* Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.

Levels of the Capability Maturity Model:

There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."

Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.

Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.

Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.

Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.

Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, shifting the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.

CMMI (Capacity Maturity Model Integration):
CMMI (Capacity Maturity Model Integration) is a model for evaluating a company's level of maturity in terms of IT developments.
CMMI is a broader version of CMM, on which it is based and from which it borrows most of its concepts, and offers best practices benchmarks for software development. The goal is to encourage companies to monitor and continually improve their processes and evaluate the maturity level of these processes on a five-level maturity scale set by the CMMI.

CMMI is a collection of best practices that meet the needs of organizations in different areas of interest. A collection of best practices that cover a particular area of interest is called a CMMI model.

CMMI currently addresses three areas of interest:

(1) Product and service development — CMMI for Development (CMMI-DEV),
(2) Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
(3) Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.

CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM.

Achieving CMMI compliance:

The traditional approach that organizations often adopt to achieve compliance with the CMMI involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs). This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM and primarily using the traditional approach. These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI.

The Software Engineering Institute’s (SEI) Team Software Process methodology and the Capability Maturity Modeling® framework have been successfully employed to accelerate progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing form Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken traditionally.

CMMI Can Benefit You:

CMMI provides

Efficient, effective assessment and improvement across multiple process disciplines in an organization
Improvements to best practices incorporated from the Software CMM
A common, integrated vision of improvement for all elements of an organization
A means of representing new discipline-specific information in a standard, proven process-improvement context

For More Information About CMMI:

Go to CMMI Web site:
http://www.sei.cmu.edu/cmmi
http://seir.sei.cmu.edu

Contact SEI Customer Relations:
Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
FAX: (412) 268-5800
customer-relations@sei.cmu.edu

With Love,
~SA

Six Sigma – A Strategy for Achieving World Class Performance

noreply@blogger.com (Sharad) — Thu, 18 Jun 2009 06:14:00 +0000

What is Sigma (σ)?

A term used in statistics to represent standard deviation, an indicator of the degree of variation in a set of a process

What is Six Sigma (6σ)?

A statistical concept that measures a process in terms of defects – at the six sigma level, there 3.4 defects per million opportunities.
A philosophy and a goal : as perfect as practically possible
A methodology and a symbol of quality

Sigma Level:
Short-term sigma levels correspond to the following long-term DPMO values (one-sided):

1 sigma = 690,000 DPMO = 31% efficiency
2 sigma = 308,000 DPMO = 69.2% efficiency
3 sigma = 66,800 DPMO = 93.32% efficiency
4 sigma = 6,210 DPMO = 99.379% efficiency
5 sigma = 230 DPMO = 99.977% efficiency
6 sigma = 3.4 DPMO = 99.9997% efficiency

These figures assume that the process mean will shift by 1.5 sigma towards the side with the critical specification limit some time after the initial study determining the short-term sigma level. The figure given for 1 sigma, for example, assumes that the long-term process mean will be 0.5 sigma beyond the specification limit, rather than 1 sigma within it, as it was in the short-term study.

Why not Four Sigma or 99.379 % ?

Every hour the postal service would lose 20,000 pieces of mail
Every day our drinking water would be unsafe for almost 15 minutes
Every week there would be 5,000 surgical operations that go wrong in some way
Every month we would be without electricity for almost seven hours

Why Six Sigma:

Money
Quality
Customer Satisfaction
Competitive Advantage
Growth
Employee Pride

Some Success Stories:

At GE, Six Sigma added more than $ 2 billion to the bottom line in 1999 alone
Motorola saved more than $ 15 billion in the first 10 years of its Six Sigma effort
AlliedSignal reports saving $ 1,5 billion through Six Sigma.

"Six Sigma is about practices that help you eliminate defects and always deliver products and services that meet customer specifications"

Cost of Poor Quality:

What is cost of scrap?
What is cost of rework?
What is cost of excessive cycle times and delays?
What is cost of business lost because customers are dissatisfied with your products or services?
What is cost of opportunities lost because you didn’t have time or the resources to take advantage of them?

Critical-to-Quality (CTQ):
Elements of a process that significantly affect the output of that process. Identifying these elements is figuring out how to make improvements that can dramatically reduce costs and enhance quality.

Six Sigma Phases:

D M A I C : Define -> Measure -> Analyze -> Improve -> Control

DEFINE: Define the project goals and customer (internal and external) deliverables

Define Customers and Requirements (CTQs)
Develop Problem Statement, Goals and Benefits
Identify Champion, Process Owner and Team
Define Resources
Evaluate Key Organizational Support
Develop Project Plan and Milestones
Develop High Level Process Map

Deliverables :
Fully trained team is formed, supported, and committed to work on improvement project.
Team charter developed, customers identified and high impact characteristics (CTQs) defined, business process mapped.

Checkpoints for Readiness
Team Readiness :
Team is sponsored by a champion or business leader.
Team formed and team leaders assigned.
Improvement team members fully trained on Six Sigma and DMAIC.

Team Charter :
Completed project management charter, including business case, problem and goal statements, project scope, milestones, roles and responsibilities, communication plan.

Customers
Customer(s) identified and segmented according to their different needs and requirements.
Data collected and displayed to better understand customer(s) critical needs and requirements.

Business Process Mapping
Completed, verified, and validated high-level 'as is' (not 'should be' or 'could be') business process map.
Completed SIPOC representation, describing the Suppliers, Inputs, Process, Outputs, and Customers.

MEASURE: Measure the process to determine current performance

Define Defect, Opportunity, Unit and Metrics
Detailed Process Map of Appropriate Areas
Develop Data Collection Plan
Validate the Measurement System
Collect the Data
Begin Developing Y=f(x) Relationship
Determine Process Capability and Sigma Baseline

Deliverables :
Key measures identified, data collection planned and executed, process variation displayed and communicated, performance baselined, sigma level calculated.

Checkpoints for Readiness
Key Measures Identified
Key measures identified and agreed upon.
High impact defects defined and identified in the business process.

Data Collection Planned and Executed
Solid data collection plan established that includes measurement systems analysis.
Data collected on key measures that were identified.

Process Variation Displayed/Communicated
Process variation components displayed/communicated using suitable charts, graphs, plots.
Long term and short term variability accounted for.

Performance Baseline/Sigma Calculation
Measure baseline process performance (capability, yield, sigma level).

ANALYZE: Analyze and determine the root cause(s) of the defects

Define Performance Objectives
Identify Value/Non-Value Added Process Steps
Identify Sources of Variation
Determine Root Cause(s)
Determine Vital Few x's, Y=f(x) Relationship

Deliverables :
Data and process analysis, root cause analysis, quantifying the gap/opportunity.

Checkpoints for Readiness
Data and Process Analysis
Identify gaps between current performance and the goal performance.

Root Cause Analysis
Generate list of possible causes (sources of variation).
Segment and stratify possible causes (sources of variation).
Prioritize list of 'vital few' causes (key sources of variation).
Verify and quantify the root causes of variation.

Quantifying the Gap/Opportunity
Determine the performance gap.
Display and communicate the gap/opportunity in financial terms.

IMPROVE: Improve the process by eliminating defects

Perform Design of Experiments
Develop Potential Solutions
Define Operating Tolerances of Potential System
Assess Failure Modes of Potential Solutions
Validate Potential Improvement by Pilot Studies
Correct/Re-Evaluate Potential Solution

Deliverables :
Generate (and test) possible solutions, select the best solutions, design implementation plan.

Checkpoints for Readiness
Generating (and Testing) Possible Solutions
Possible solutions generated and tested.

Selecting The Best Solution(s)
Optimal solution selected based on testing and analysis.
New and improved process ('should be') maps developed.
Cost/benefit analysis of optimal solution(s).
Small-scale pilot for proposed improvement(s).
Pilot data collected and analyzed.
Improved process ('should be') maps modified based on pilot data and analysis.
Project impact on utilizing the best solution(s).

Designing Implementation Plan
Solution implementation plan established, including schedule/work breakdown structure, resources, risk management plan, cost/budget, and control plan.
Contingency plan established.

CONTROL: Control future process performance

Define and Validate Monitoring and Control System
Develop Standards and Procedures
Implement Statistical Process Control
Determine Process Capability
Develop Transfer Plan, Handoff to Process Owner
Verify Benefits, Cost Savings/Avoidance, Profit Growth
Close Project, Finalize Documentation
Communicate to Business, Celebrate

Deliverables :
Documented and implemented monitoring plan, standardized process, documented procedures, response plan established and deployed, transfer of ownership (project closure).

Checkpoints for Readiness
Monitoring Plan
Control plan in place for sustaining improvements (short and long-term).

Process Standardization
New process steps, standards, and documentation are ingrained into normal operations.

Documented Procedures
Operating procedures are consistent.
Knowledge gained on process is shared and institutionalized.

Response Plan
Response plans established, understood, and deployed.

Transfer of Ownership (Project Closure)
Transfer ownership and knowledge to process owner and process team tasked with the responsibilities.

DMADV: Define -> Measure -> Analyze -> Design -> Verify

The basic method consists of the following five steps:

* Define design goals that are consistent with customer demands and the enterprise strategy.
* Measure and identify CTQs (characteristics that are Critical To Quality), product capabilities, production process capability, and risks.
* Analyze to develop and design alternatives, create a high-level design and evaluate design capability to select the best design.
* Design details, optimize the design, and plan for design verification. This phase may require simulations.
* Verify the design, set up pilot runs, implement the production process and hand it over to the process owners.

DMADV is also known as DFSS, an abbreviation of "Design For Six Sigma"

Tools and Roles for Six Sigma:

Process Maping:

Creating flowcharts of the step in a process – operations, decision points, delays, movements, handoffs, rework, loops, and controls or inspections.
process map is illustrated description of how a process work.

Design of Experiments (DOE):

DOE is a structured, organized method for determining the relationship between factors (Xs) affecting a process and the output of that process (Y).

XY Matrix:

A group of rows and columns, with one set of increments marked along the X (horizontal) axis and another set of increments marked along the Y (vertical) axis.
The purpose of using XY matrix is to study and understand the relationship between what you are putting into a process and what your customer is getting out of it.
The XY matrix allows the team to identify gaps, areas for improvement.

Measurement System Analysis:

The goal of this tool is to ensure that your measurement system is statically confident – that it’s both accurate and precise each and every time it is used.
Undertaken during Measure phase, your MSA determines whether or not you can take a certain measurement and repeat or reproduce it among different people who take the same measurement.

Process Capability Tool:

Process capability tool is the measure of a process being able to meet specification requirements and fulfill customer CTQ needs on a long term basis.

Hypothesis Testing:

Investigating a theory about the suspected cause (s) of a particular effect in a process to determine if it is correct.
It’s a compass that points you directly to the vital few factors that are most affecting your process.

Failure Mode Effect Analysis:

The manner in which a part or process can fail to meet a specification, creating a defect or non-conformance, and the impact on the customer if that failure mode is not prevented or corrected.

Control Plan:

A detailed assessment and guide for maintaining all the positive changes you, your black belt, and the project team have made.
It ensures that all your analysis and efforts stay in effect and that you have information at your disposal to prevent backsliding or a return to less than optimal performance standard.

Key Roles for Six Sigma:

Executive Leadership: Includes CEO and other key top management team members. They are responsible for setting up a vision for Six Sigma implementation.

Champions: Are responsible for the Six Sigma implementation across the organization in an integrated manner. Champions also act as mentor to Black Belts.

Master Black Belts: dentified by champions, act as in-house expert coach for the organization on Six Sigma. They devote 100% of their time to Six Sigma.

Black Belts: Operate under Master Black Belts to apply Six Sigma methodology to specific projects. They primarily focus on Six Sigma project execution.

Green Belts: Are the employees who take up Six Sigma implementation along with their other job responsibilities. They operate under the guidance of Black Belts and support them in achieving the overall results.

Six Sigma Do's:

Do communicate the commitment company-wide
Do demonstrate the commitment of company leaders
Do empower your key human resources
Do provide on-site mentoring for black belts
Do be patient at the inception of you six Sigma initiative
Do claim and advertise early “wins”
Do benchmark
Do establish project baseline and

Criticism:

Six Sigma has made a huge impact on industry and is widely employed as a business strategy for achieving and sustaining operational and service excellence. However, there have also been various criticisms of Six Sigma.

Lack of originality:

Noted quality expert Joseph M. Juran has described Six Sigma as "a basic version of quality improvement," stating that "[t]here is nothing new there. It includes what we used to call facilitators. They've adopted more flamboyant terms, like belts with different colors. I think that concept has merit to set apart, to create specialists who can be very helpful. Again, that's not a new idea. The American Society for Quality long ago established certificates, such as for reliability engineers."

Role of consultants:

The use of "Black Belts" as itinerant change agents is controversial as it has created a cottage industry of training and certification. Critics argue there is overselling of Six Sigma by too great a number of consulting firms, many of which claim expertise in Six Sigma when they only have a rudimentary understanding of the tools and techniques involved.

The expansion of the various "Belts" to include "Green Belts," "Master Black Belts" and "Gold Belts" is commonly seen as a parallel to the various "belt factories" that exist in martial arts.

Potential negative effects:

A Fortune article stated that "of 58 large companies that have announced Six Sigma programs, 91 percent have trailed the S&P 500 since." The statement is attributed to "an analysis by Charles Holland of consulting firm Qualpro (which espouses a competing quality-improvement process)." The gist of the article is that Six Sigma is effective at what it is intended to do, but that it is "narrowly designed to fix an existing process" and does not help in "coming up with new products or disruptive technologies." Many of these claims have been argued as being in error or ill-informed.

A Business Week article says that James McNerney's introduction of Six Sigma at 3M may have had the effect of stifling creativity. It cites two Wharton School professors who say that Six Sigma leads to incremental innovation at the expense of blue-sky work. This phenomenon is further explored in the book, Going Lean, which provides data to show that Ford's "6 Sigma" program did little to change its fortunes.

Based on arbitrary standards:

While 3.4 defects per million opportunities might work well for certain products/processes, it might not be ideal or cost-effective for others. A pacemaker process might need higher standards, for example, whereas a direct mail advertising campaign might need lower ones. The basis and justification for choosing 6 as the number of standard deviations is not clearly explained. In addition, the Six Sigma model assumes that the process data always conform to the normal distribution. The calculation of defect rates for situations where the normal distribution model does not apply is not properly addressed in the current Six Sigma literature.

Criticism of the 1.5 sigma shift:

Because of its arbitrary nature, the 1.5 sigma shift has been dismissed as "goofy" by the statistician Donald J. Wheeler. Its universal applicability is seen as doubtful.

The 1.5 sigma shift has also been contentious because it results in stated "sigma levels" that reflect short-term rather than long-term performance: a process that has long-term defect levels corresponding to 4.5 sigma performance is, by Six Sigma convention, described as a "6 sigma process." The accepted Six Sigma scoring system thus cannot be equated to actual normal distribution probabilities for the stated number of standard deviations, and this has been a key bone of contention about how Six Sigma measures are defined. The fact that it is rarely explained that a "6 sigma" process will have long-term defect rates corresponding to 4.5 sigma performance rather than actual 6 sigma performance has led several commentators to express the opinion that Six Sigma is a confidence trick.

~SA

KAIZEN - A STRATEGY FOR PERFORMANCE EXCELLENCE

noreply@blogger.com (Sharad) — Wed, 10 Jun 2009 05:06:00 +0000

KAIZEN (INTRODUCTION):

Kaizen (改善, Japanese for "improvement") is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life. When applied to the workplace, Kaizen activities continually improve all functions of a business, from manufacturing to management and from the CEO to the assembly line workers. By improving standardized activities and processes, Kaizen aims to eliminate waste.
Kaizen was first implemented in several Japanese businesses during the country's recovery after World War II, including Toyota, and has since spread to businesses throughout the world.
Masaaki Imai is known as developer of Kaizen.

What Does Kaizen Mean?

The original kanji characters for this word are: 改善
In Japanese this is pronounced "kaizen".
改 ("kai") means "change" or "the action to correct".
善 ("zen") means "good".

Make it easier by studying it, and making the improvement through elimination of waste.

How It works:

Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work ("muri"), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes. The philosophy can be defined as bringing back the thought process into the automated production environment dominated by repetitive tasks that traditionally required little mental participation from the employees.
People at all levels of an organization can participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group. At Toyota, it is usually a local improvement within a workstation or local area and involves a small group in improving their own work environment and productivity. This group is often guided through the kaizen process by a line supervisor; sometimes this is the line supervisor's key role.
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. Hence the English usage of "kaizen" can be: "continuous improvement" or "continual improvement."
This philosophy differs from the "command-and-control" improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.
In modern usage, a focused kaizen that is designed to address a particular issue over the course of a week is referred to as a "kaizen blitz" or "kaizen event". These are limited in scope, and issues that arise from them are typically used in later blitzes.

Why Kaizen:

CPI (Continual Performance Improvement)

Data Driven Methodology to Magnify Impact of Process Improvement
Apply Control Techniques to Eliminate Erosion of Improvements
Proceduralize/Standardize Improvements for Improved Maintenance of Critical Process Parameters

Kaizen

Use Small Teams to Optimize Process Performance by Implementing Incremental Change
Apply Intellectual Capital of Team Members Intimate with Process

The Nine types of waste:

Overproduction
Delays (waiting time)
Transportation
Process
Inventories
Motions
Defective products
Untapped resources
Misused resources

3 Main Principal of KAIZEN:

Consider the process & the Results.
The need to look at the entire process of the job at hand and to evaluate the job as to the best way to get the job done.
Kaizen must be approached in such a way that no one is blamed and that the best process is put into place.

Key Features of KAIZEN:

Widely Applicable - Can be used in both manufacturing and non-manufacturing enviornments.
Highly Effective & Results Oriented - Kaizen event will generate Quick results, Measurable results, Estabilish the baseline, and Measure the change.
A Learning Experience - Every member of Kaizen team will walk away from the event learning something new.
Team Based & Cross Functional - Team members can be form various function of the business. Top managment participation is encouraged.

PHASES IN KAIZEN

Step#0 - Event Prepration - Select event area, team, and create team package.
Step#1 - Define the Scope & Goals of the event
Step#2 - Train the team, Review the World Class Tool(s)and Techniques that Support the Team's Goal
Step#3 - Walk the Event Area, Observe Physical Layout, Review Videos if Available. This Steps start the idea creation process
Step#4 - Collect Data on Event Area (Scrap, Production, Time Studies, Videos, Etc) - Develop/Obtain the baseline performance measurements
Step#5 - Brainstrom Ideas - Thinking "outside the box" and piggybacking important here.
Step#6 - Use Multi-Voting to Prioritize Top 8-10 ideas that will be Worked on immediately
Step#7 - Form Sub-Teams to Go Out and Try/Implement ideas

These steps are Shorten into:

Select an Event
Plan an Event
Implement an Event
Follow-up to an Event

BENEFITS OF KAIZEN

KAIZEN reduces waste like Inventory waste, Time waste, Workers motion
KAIZEN improves Space utilization, Product quality
Results in Higher employee moral and job satisfaction, and lower turn over

~SA

Importance of "Work" in our life

noreply@blogger.com (Sharad) — Tue, 02 Jun 2009 07:59:00 +0000

Our life is an odd mixture of different moments of action and inaction, work and rest. Work provides us with an inner creative joy. It saves us from the dullness and boredom of life. It puts our energies to a proper use. Unused energies create disorders in us. They make us physically unhealthy and mentally unhappy. Time hangs heavy on our shoulders when there is no work. It provides us with money for our life hood. It makes our life meaningful and peaceful. Idleness is more tiresome and painful than work. Even the most unpaid, unimportant and unpleasant work is better than no work. For a really useful and happy work, two things are necessary. They are skill and constructiveness. Constructive work is rather unpleasant in the beginning, but very pleasant at the end. For deriving maximum pleasure from life, we must consider life as a whole, a unity and a system. Good Work pays and evil work destroys at the end. Every man who learns some useful skill enjoys it till he improves himself completely. The element of constructiveness is an important source of happiness. When a worker builds up something new. He feels encouraged and elevated and thus gets pleasure from his creative work. Where there is no need, there would be no work. Where there is no work, there would be no joy in life.

~SA

Quality

noreply@blogger.com (Sharad) — Mon, 01 Jun 2009 04:51:00 +0000

Today i'm going to share my thought about term "quality". As most of my friends know that it is related to my job, so i thought i should share something with you guys.
Lets start with the term Quality...
What is quality:
The term 'quality' is often used in a vague, blurred way. If someone talks about 'working on quality', they may simply mean activities designed to improve the organisation and its services.
Quality is essentially about learning what you are doing well and doing it better. It also means finding out what you may need to change to make sure you meet the needs of your service users.

Quality is about:
@ knowing what you want to do and how you want to do it
@ learning from what you do
@ using what you learn to develop your organisation and its services
@ seeking to achieve continuous improvement
@ satisfying your stakeholders - those different people and groups with an interest in your organisation.

The domain of the quality professional has changed. From its humble beginnings in manufacturing, it is now expected, along with other infrastructure professions, such as IT, HR and finance, to contribute at the organisational level. Unlike those other professions, quality expertise can be hard to define, perhaps because there are many views of what business-level quality means.
At its simplest level, quality answers two questions: ‘What is wanted?’ and ‘How do we do it?’ Accordingly, quality’s stomping ground has always been the area of processes. From the bread and butter of ISO 9000, to the heady heights of TQM, quality professionals specify, measure, improve and re-engineer processes to ensure that people get what they want.

So what is wrong?
If requirements are wrong, then failure is guaranteed. Focus is the domain of QA where, without a specification, quality cannot be measured and thus controlled. You cannot have zero defects if you do not have a standard against which to measure defectiveness.
This reflects the early days, where quality was clearly about product. Quality Control, and later Quality Assurance, was our domain - we didn’t care about customers; the research and design department was responsible for designing the job and sales and marketing for selling it. But those halcyon days of definitive specifications and jobs for life are long gone.
I takes a step further down the value chain, to the use of the product or service (at which point customers had forced their way into the frame), i still presupposes that we can fully understand how the product will be used, which is a great challenge (and not always possible). You know, Some things are ‘unknown and unknowable’.
ISO 8402 recognises this uncertainty with its ‘implied need’. It uses the word ‘entity’ as opposed to the ‘product or service’ definition of its earlier (1986) version, indicating a broadening uncertainty. Nonetheless, it suffers again from a simplistic, single-minded focus - all we need to do is to figure out what is wanted and then deliver it.
The quality models are a step further into broader business. Here, although processes are important, quality is much more about people: customers are there, but so too are stakeholders - employees, partners, suppliers, shareholders and society. Perhaps wisely, the models avoid nailing down a specific definition of quality, leaving us without a definition that encompasses a broader business view.
ISO9000:2000 steps in this direction also, talking about ‘customer and other interested parties’, but leaves the definition of quality at a rather generalised ‘degree to which a set of inherent characteristics fulfils requirements’.

I hope that these words will help you to understand the term "Quality"

Luv,
~SA