Skip to main content

2 Different sources of defects in Software development

Miscommunication is a common factor, which can be defined as inaccurate statements or information missing that is required for the action to be done successfully. This miscommunication ends up in the documentation or verbal communication that occurs.

Instead of spending time to make sure everything is accurate, statements are made that are untrue or unclear. When this occurs at the beginning of the change process the bad information continues down through the process. Decisions and design are made based on it. At some point it gets realized that the information is bad and a defect is created. In the common project process that could be classified as linear, most defects are not found until in the later phase of development and unit testing has started.

[More IT Development Jobs]
[More IT Development Jobs]
The other type of defect is a system-generated result.

This would be similar to a defect a machine makes in manufacturing. Even though the input is accurate, the process itself causes a defect to occur. The original process was prone to defects no matter how careful the work was done. Randomly at some point in time a widget would not be created correctly. When the process was changed to reduce the number of handoffs and some steps were moved around, the possibility of creating a defect was reduced.

This same concept occurs with processes. As processes add more handoffs and complexity, the process itself is introducing more spots in which a defect can occur, which increases the possibility of defects occurring. It becomes a catch 22 in that when companies have issues with the number of defects, they create more complex processes to try to stop them from happening. By doing this they only add to the problem. The defects initially do go down, but it's only because of the amount of additional resources and the priority given to the defects. Once both resources and priority are moved to other things, then the defect counts go back up and might even increase because with the more complex process there are more spots in which a defect might occur.

It would be wonderful if processes could be made to eliminate all defects, but they don't. There is always some unique situation—whether machine or human—that will always create a defect. Attaining zero defects in most situations is impossible. The best that can be done is to greatly reduce the risk of having a defect. This is not to say that each defect does not need to be analyzed, but every defect does not need to be resolved. For system-generated ones it might not be monetarily feasible to make changes to eliminate them from happening. Even Six Sigma addresses this by originally stating that the quality goal is to obtain 3.4 defect parts per million (PPM) opportunities. It would be impossible and also very costly to attempt to obtain a defect ratio of 0.00.

W. Edwards Deming's point #3 states that processes need to be created so that instead of opening up the possibility of defects occurring they will eliminate defects. If the possibility of defects is eliminated, then no rework and mass inspections are needed. Companies need to look at their processes and make changes to reduce the possibility of defects. Fewer handoffs in a process is a good start. Proper staffing of work is another process.

Comments

Popular posts from this blog

R Vs SAS differences to read today

Statistical analysis should know by every software engineer. R is an open source statistical programming language. SAS is licensed analysis suite for statistics. The two are very much popular in Machine learning and data analytics projects.
SAS is analysis suite software and R is a programming language R ProgrammingR supports both statistical analysis and GraphicsR is an open source project.R is 18th most popular LanguageR packages are written in C, C++, Java, Python and.NetR is popular in Machine learning, data mining and Statistical analysis projects. SASSAS is a statistical analysis suite. Developed to process data sets in mainframe computers.Later developed to support multi-platforms. Like  Mainframe, Windows, and LinuxSAS has multiple products. SAS/ Base is very basic level.SAS is popular in data related projects. Learn SAS vs R Top Differences between SAS Vs R Programming SAS AdvantagesThe data integration from any data source is faster in SAS.The licensed software suite, so you…

Blue Prism complete tutorials download now

Blue prism is an automation tool useful to execute repetitive tasks without human effort. To learn this tool you need the right material. Provided below quick reference materials to understand detailed elements, architecture and creating new bots. Useful if you are a new learner and trying to enter into automation career. The number one and most popular tool in automation is a Blue prism. In this post, I have given references for popular materials and resources so that you can use for your interviews.
RPA Blue Prism RPA blue prism tutorial popular resources I have given in this post. You can download quickly. Learning Blue Prism is a really good option if you are a learner of Robotic process automation.
RPA Advantages The RPA is also called "Robotic Process Automation"- Real advantages are you can automate any business process and you can complete the customer requests in less time.

The Books Available on Blue Prism 
Blue Prism resourcesDavid chappal PDF bookBlue Prism BlogsVi…

Top Differences Read Today Agile vs Waterfall model

The Agile and Waterfall both models are popular in Software development. The Agile model is so flexible compared to waterfall model. Top differences on Waterfall vs Agile give you clear understanding on both the processes. Waterfall ModelThe traditional model is waterfall. It has less flexibility.Expensive and time consuming model.Less scalable to meet the demand of customer requirements.The approach is top down. Starting from requirements one has to finish all the stages, till deployment to complete one cycle.A small change in requirement, one has to follow all the stages till deployment.Waterfall model creates idleness in resource management. Agile ModelAgile model is excellent for rapid deployment of small changesThe small split-requirements you can call them as sprintsLess idleness in resource management.Scope for complete team involvement.Faster delivery makes client happy.You can deploy changes related to compliance or regulatory quickly.Collaboration improves among the team.