Broken window effect-who's breaking the first window? Go

Broken window effect-who's breaking the first window?
Sociologists Jamesq.wilson and georgel.kelling in the Brokenwindows: "A House if the window is broken, no one to repair, and soon, the other windows will be inexplicably broken, a wall, If some graffiti has not been washed away, soon, the wall is full of messy, unsightly things; a very clean place, people are embarrassed to throw rubbish, but once there is rubbish on the ground, people will not hesitate to throw, the slightest shame "
InDevelopment andTest, who is breaking the window?
Bad.DemandManagement
Demand is a change, in practice, to achieve accurate and accurate definition of requirements is not possible. This is the right word, but it was wrongly used. So there's a demand forDocuments that do not pay attention to, do not maintain, have a low quality of the requirements of the document, there are problems of the problem of the demand, there is inconsistent with the demand, change the demand, but also the need is unclear, but has been achieved. (Need First orSystem first, has not been clear). Requirements are everything developed and testedworkThe basis. If the demand is unclear, it achievesfunction, should be based on the implementation of the function of the definition of this requirement, the face of the problem may be the definition of demand is the case of the wrong, but not to face the definition of the demand is not clear, on the other hand realize the function of the two situations. Moreover, the implementation of the function may also be wrong. In vain to increaseDemand ManagementDegree of complexity. In the face of changes in demand, to do the two-way tracking of demand and deliverables, on the one hand to achieve the system, to maintain consistency, on the other hand, through the implementation of the system to redefine the ambiguous requirements, maintain consistency, and not the possibility of existence. The simpler the management process, the more effectively you can track it.
No, No.Unit Testand integration Testing
No unit tests are present. Do you have integration testing? The integration test report does not show that the system modules areHow is it integrated, bottom-up or top-down? The reality is to put all the packages together and then test them to form so-called integration tests.
A mere formality of testing
For example, integration testing purposes are ambiguous, testingShort time, insufficient testing, a mere formality, the problem and hope pinned in the next link. For exampleSystem Testingand acceptance testing phases.
Non-measurable
Testability is a guideline for measuring modules. Since it is the norm, the natural height is high, and it is naturally difficult to reach it. But not because it is difficult to do. For example, the Energy efficiency management systemData sources are always a problem, data volume, data accuracy, data validity, and so on, if not meet the requirements, will lead to the non-testability of data-related items. When the number of non-measurable items, the tester will give up the willingness to continue testing. At this point, another problem is raised, and the parts that can be tested are discarded.
Modules that are not highly reusable
For example, the login registration module in our system, the implementation of severalThere is no special demand change for the project. But there are different problems in every project. This unreasonable situation causes testers to be skeptical about the reusability of the module and has no confidence in it. So every project has to be re-tested, causing waste. If the reusability is high, there is reason in the test, have confidence to save the module test, or spot test, save time without facing the quality risk.
Unfriendly human-Computer interaction
Human-Computer interaction is a big problem, but it can't afford to pay attention. The interface is not friendly, personal color composition is strong, simple problem complex processing, not convenient operation leftUser, the interface renders the function and the actual logic does not match, needs the user to grope, increases the user to operate the difficulty, hoped through the user manual to evade the question.Software human-computer interaction, whether it is the industry quasi-test, or industry habits, have developed more mature. If you leave an uncomfortable operation to the user, write it in the user's manual, and the next thing you do is to handle more of it in the same way. Because this is a reasonable way to circumvent the problem. A problem, if you can nowSolution, this is the most economical and safest way to handle it. Human-computer interaction to achieve the "WYSIWYG" effect.
The argument of useless theory
The company is importingCMMI, the project is takingAgileWay. There are concerns that CMMI threatens agile projects. For example, CMMI emphasizes documentation, but agility is the opposite. But when testing requires documentation, agility becomes imperial sword, and abuse is extremely extreme. Agile does not emphasize an important purpose of documentation is to save and eliminate waste. What does the actual project do? Some project system, the test environment is unclear, the test scope is not divided, the submission of the test system is not done, directly will also be debugging for testing, so there are many debuggingThe non-implemented functionality is not registered. Are these not documented or eliminated before the test? During the test, most of the time is used to understand the real situation of the system. Is it the agility to eliminate waste or increase waste? When waste is increasing, the appearance of broken windows is inevitable. The current situation, such problems will still exist for a long time. In order to understand this problem, we may as well make some more extension.
For change, there are generally 2 kinds of treatment, one is "status quo", one is "embrace change". The premise of "status quo" is to have a mature organization structure and flexible processing process. CMMI is doing this thing. I think it would be wise to "embrace change" before you reach this ability. The characteristics of the project in practice vary widely, so there are agile, XP, RUP, and so on these excellent ideas and models to solve the actual problems. When it comes to solving problems, we have to mention another concept, "best practices." What is "best practice"? You use the way 1, I use the way 2, which is the best? That's how I understood it before. Later found that this is not the case. The practice of doing things can be called best practices. Does agile have non-documented practices to deal with changes in demand, or other issues? If so, this is its best practice. If not, is it because Agile does not emphasize documentation and does not take this best practice to avoid overlapping with CMMI philosophy? There is no saying that best practices are born. Every development model, ideas have interoperability best practices.
Will not be a problem evolution is problematic
In the test front, if the objective problem has the corresponding processing and tracking measures, even if not finished in the testing phase, it will be improper is a problem. If not, this is a problem in the test phase and is the most serious problem to treat. Although you have objective reasons. At the front end the processing is not processed and there is reason to believe that the problem is out of control and skeptical about whether it will be handled. The front-end link problem is banished to the back-end link, hope that the control of the back-end link, is the breeding environment of broken windows.
Do not pay attention to the accumulation of organizational process assets and knowledge Base
Each project, generated code, document,Experience summary, and so on need to pay attention to the usual accumulation, the formation of organizational process assets. For future use by the organization. If only stay in the accumulation of personal experience, no project accumulation, organizational accumulation, no knowledge base, this efficiency is quite low. Change a person, once do the thing to go again. Individual efficiency does not mean that projects or organizations are efficient. Before the introduction of IPD, Huawei concluded that one of the findings ofIBM 's research was that Huawei did not have time to do the right thing at once, but had time to do the same thing over and over again. Can this sharply's conclusion today arouse the vigilance of practitioners? Not necessarily so. For example, the requirements have not been understood clearly, the internal not unified opinion of the case, began to encode, resulting in late internal cross-reference, or repeatedly modify the code, or modify the code more difficult, and change the requirements to meet the implemented code. This repetition, useless labor, is also a serious broken window performance.
Software Development and testing all aspects like a window, we do is to open the window, close the window, and try to avoid to break the window, especially the first window, broken also need to repair quickly, otherwise the software will be broken window effect, a fan is broken.

Broken window effect-who's breaking the first window? Go