Currently or since I know myself as a professional, software failures are largely responsible for costs and time in the software development process.
While it is not possible to remove all existing errors in a given application, it is possible to considerably reduce the number of errors using a more elaborate testing infrastructure, which allows for identifying and removing defects earlier and more effectively.
These defects can result from various causes such as errors of knowledge, communication, analysis, transcription, coding, etc. There are basically three ways to handle software flaws:
1. Fault-avoidance: With appropriate specification, design, implementation and maintenance activities always aiming to avoid failures in the first place. It includes the use of advanced software construction methods, formal methods, and reuse of trusted software blocks.
2. Fault-elimination: Analytical compensation for errors committed during specification, design and implementation. Includes verification, validation and testing.
3. Fault-tolerance: real-time compensation of residual problems such as changes out of specification in the operating environment, user errors, etc.
Due to the fact that fault-avoidance is economically impractical for most companies, the technique of fault elimination is generally adopted by software manufacturers
In the US, do these errors move the software market by approximately 50 billion dollars, and in Brazil and South America? We can see that there is a culture of everything by the result, and after delivery by delivery, in many projects and forgotten the quality be it in the software architecture or in the choice of the project implementation strategy, the DEADLINE is focused by the DEADLINE.
Another point is the bureaucratization of technical activities, process must exist but these should also be support to the objectives and not against the objectives that includes being agile, safe, reusable, practical and that make a culture in the company be it with 10 professionals or with 100 In a company.
The culture of testing is old, as it says in King Chelomoh's Cohelet book, nothing new is just not revealed.
The practice involves the implementation of a system starting with test cases of an object, this is old, I at least have known these techniques since 1999, I will cite only one that defends this idea [Gelperin and Hetzel 1987]. Minimize the errors by focusing on the tests, and today as we are in the era of "JS frameworks", there is a semantics of confusing the implementation framework with work process framework with tools of griffe, which does not apply if they are not tested in the process by All, for all, not only by the 18-year-old project architect, this 18-year-old nowadays grant the role of software architect, senior software development positions to good early professionals, but with little experience, which For me 1996 was almost impossible to have a Jr. level in my classificatory parts of technical activities of the profession, I thought more imperative implementation than clear techniques, there have been many improvements, but today TDD - Test driven development can be put at high risk If you do not have experience in IT projects with software development with serious errors and also great achievements.
In many different techniques, used in the market and tested in the academic world, and professional can, I say by myself also, that the use of this technique is possible to reduce the complexity of software, increasing the maintainability of it. Failures are easily identified even in the development stage thanks to continuous feedback given to the programmer. The test units created allow you to more easily evaluate new defects that may have been inserted in the software facilitating the development of successive releases.
But a detail the professionals who do this are also with attributes of programmers, systems analysts know the world of implementation, this is my opinion for the success of TDD, adjust to lead to good results.
No comments:
Post a Comment