"If you can't explain it simply, you don't understand it well enough." — Albert Einstein
I have completed my 17 years working in Information Technology industry. In past 17 years I have realized the essence of above statement by Einstein.
Most of the times, people can't explain things simply. The problem IT industry is seeing today is the focus on "Information" has been lost completely and the whole industry is running behind "Technology"!
I wish all the best to the industry on this special day of 10/10/10 at 10AM IST.
Sunday, October 10, 2010
Friday, October 8, 2010
Review of "Quality Reviews"
Review means a "critical inspection" of a product or a process by someone who was not involved in the creation or regular operation of it.
Review is considered to be one of the important methods of Quality Assurance (QA) of software systems.
Review in software product / development:
Now, let us take a "review" of the review process in software product.
1. A software deliverable is architected as per the business requirement. The software architecture is reviewed by a reviewer to assure that architecture meets the functional and non-functional (scalability/performance/interoperability etc.,) requirements of the business.
2. Software deliverable-s are designed as per the architecture. The design is reviewed by a reviewer again to assure the design meets the architecture.
3. The design is implemented into software program-s (code) and the code is reviewed with reference to the design.
4. Each unit of code is also tested by the developer or an independent tester to make sure code has met the design specifications!
5. All the different units of software are integrated to realize the overall architecture of the software product. The integrated product is tested for functional and non-functional requirements.
6. The product is released to the customer.
So, review is preventive measure of quality assurance that helps in avoiding injection of bugs where as testing is a reactive method of finding and fixing the bugs after the bugs are injected into the product.
Why software still have bugs?
In my opinion, the primary cause is lack of "self-review" of the work products delivered by the individuals. Each individual should be encouraged to develop a culture of reviewing the work-product (let it be the architecture, a design, a unit of code, a test spec, or anything else) before it goes out into the software development process chain. Once the organization is successful in this mechanism, the quality will automatically improve and the cost of QA will considerably reduce.
Note: QA managers need not worry... They still have their jobs safe!! Guess WHY?
Review in process outsourcing:
Looking from a different perspective of BPO or ITO scenarios, the quality of a process where development of a "deliverable unit" costs nearly same as the review of that unit, the review adds a 100% overhead and not a solution for the quality assurance. The philosophy should be driving the workforce to "Do it right first time"
within the execution of the process.
But, a Business Process Review and transformation to:
a. Identify possible scope of improvement
b. Evaluate the impact of change
c. implementing the proposed transformation in a smooth manner
will help the process to be more efficient with an improved productivity and customer satisfaction.
Conclusion:
a better process --> a better quality product.
Hence one should "review" the process first to improve the process efficiency and then focus on "review" of individual products produced by the process for a better quality.
Software development is also a process! Increased focus on a review of a wrong thing will not result in the improved quality.
Review is considered to be one of the important methods of Quality Assurance (QA) of software systems.
Review in software product / development:
Now, let us take a "review" of the review process in software product.
1. A software deliverable is architected as per the business requirement. The software architecture is reviewed by a reviewer to assure that architecture meets the functional and non-functional (scalability/performance/interoperability etc.,) requirements of the business.
2. Software deliverable-s are designed as per the architecture. The design is reviewed by a reviewer again to assure the design meets the architecture.
3. The design is implemented into software program-s (code) and the code is reviewed with reference to the design.
4. Each unit of code is also tested by the developer or an independent tester to make sure code has met the design specifications!
5. All the different units of software are integrated to realize the overall architecture of the software product. The integrated product is tested for functional and non-functional requirements.
6. The product is released to the customer.
So, review is preventive measure of quality assurance that helps in avoiding injection of bugs where as testing is a reactive method of finding and fixing the bugs after the bugs are injected into the product.
Why software still have bugs?
In my opinion, the primary cause is lack of "self-review" of the work products delivered by the individuals. Each individual should be encouraged to develop a culture of reviewing the work-product (let it be the architecture, a design, a unit of code, a test spec, or anything else) before it goes out into the software development process chain. Once the organization is successful in this mechanism, the quality will automatically improve and the cost of QA will considerably reduce.
Note: QA managers need not worry... They still have their jobs safe!! Guess WHY?
Review in process outsourcing:
Looking from a different perspective of BPO or ITO scenarios, the quality of a process where development of a "deliverable unit" costs nearly same as the review of that unit, the review adds a 100% overhead and not a solution for the quality assurance. The philosophy should be driving the workforce to "Do it right first time"
within the execution of the process.
But, a Business Process Review and transformation to:
a. Identify possible scope of improvement
b. Evaluate the impact of change
c. implementing the proposed transformation in a smooth manner
will help the process to be more efficient with an improved productivity and customer satisfaction.
Conclusion:
a better process --> a better quality product.
Hence one should "review" the process first to improve the process efficiency and then focus on "review" of individual products produced by the process for a better quality.
Software development is also a process! Increased focus on a review of a wrong thing will not result in the improved quality.
Friday, October 1, 2010
Binding Energy of Software Systems
When we study basics of atomic physics, we came to know that "A bound system has typically lower potential energy (i.e., mass) than its constituent parts" To make it into simple words, the total mass of all nucleons is more than the mass of nucleus formed by them. This mass deficit when converted to energy equivalent is called binding energy. That is the "force" which keeps the system together and not let the different constituent components fall apart!
So, In software terms, this is the effort that has gone into the "integration" of the different system components into its final form of Business Application.
Traditionally the integration has followed different models in the software systems.
Silos: Multiple software components were developed on a specific technology / programming language like COBOL, C etc., and they are integrated vertically using the procedure calls and RPCs. It is difficult to integrate with a component that is outside the technology.
Star/Spaghetti i.e., point to point integration: In this method, different components of a business application talk to each other using the flat files, or other methods. As a need for integration arises, the necessary interface should be developed and deployed on both the interfacing components of the business application. Soon, we will have a very complex spaghetti created that is very difficult to maintain.
Hub and Spoke based EAI: To overcome the standardization problems of point to point interfaces, each component should talk a "common language" with a central HUB that mediates all the integration between the enterprise business systems in that common language. This technology has developed several standard adaptors for common business components.
Enterprise Service Bus (ESB): This is the most modern integration technique available today. The key difference is that the central HUB is replaced with a more open set of protocols that can integrate the business components beyond a single enterprise. It is more open and allows more loosely coupled, heterogeneous components to talk to each other by providing more sophisticated "translation" services to them.
So, it is important that sufficient "binding energy" is in the Enterprise Business System and the CORRECT structure/method is used for the integration to keep the software strong (for operations) and flexible (for tackling the changes) all the way through its lifetime.
For more information on binding energy (atomic physics) : http://en.wikipedia.org/wiki/Binding_energy
For more on Patterns in Business Service Choreography using ESB (IBM redbook): http://www.redbooks.ibm.com/redpapers/pdfs/redp3908.pdf
So, In software terms, this is the effort that has gone into the "integration" of the different system components into its final form of Business Application.
Traditionally the integration has followed different models in the software systems.
Silos: Multiple software components were developed on a specific technology / programming language like COBOL, C etc., and they are integrated vertically using the procedure calls and RPCs. It is difficult to integrate with a component that is outside the technology.
Star/Spaghetti i.e., point to point integration: In this method, different components of a business application talk to each other using the flat files, or other methods. As a need for integration arises, the necessary interface should be developed and deployed on both the interfacing components of the business application. Soon, we will have a very complex spaghetti created that is very difficult to maintain.
Hub and Spoke based EAI: To overcome the standardization problems of point to point interfaces, each component should talk a "common language" with a central HUB that mediates all the integration between the enterprise business systems in that common language. This technology has developed several standard adaptors for common business components.
Enterprise Service Bus (ESB): This is the most modern integration technique available today. The key difference is that the central HUB is replaced with a more open set of protocols that can integrate the business components beyond a single enterprise. It is more open and allows more loosely coupled, heterogeneous components to talk to each other by providing more sophisticated "translation" services to them.
So, it is important that sufficient "binding energy" is in the Enterprise Business System and the CORRECT structure/method is used for the integration to keep the software strong (for operations) and flexible (for tackling the changes) all the way through its lifetime.
For more information on binding energy (atomic physics) : http://en.wikipedia.org/wiki/Binding_energy
For more on Patterns in Business Service Choreography using ESB (IBM redbook): http://www.redbooks.ibm.com/redpapers/pdfs/redp3908.pdf
Subscribe to:
Posts (Atom)
