Information Technology Problem Solving
Information Technology Problem Solving
This paper will disclose a logical way to deal with critical thinking. In spite of the fact that it is composed to address Information Technology related issues, the ideas may likewise be relevant in different orders. The strategies, ideas, and systems portrayed here is the same old thing, yet it is stunning what number of "issue solvers" neglect to utilize them. In the middle of I will incorporate some genuine models.
For what reason do issue solvers surmise instead of following a logical way to deal with critical thinking? Possibly on the grounds that it feels snappier? Perhaps an absence of involvement in productive critical thinking? Or then again perhaps on the grounds that it feels like diligent work to do it deductively? Possibly while you continue speculating and not so much illuminating, you produce more salary and include some employer stability? Or then again perhaps on the grounds that you damage the main rule of critical thinking: comprehend the issue.
Standard #1. Comprehend the *real* issue.
Is it safe to say that it isn't evident that before you can tackle, you have to comprehend the issue? Possibly. Yet, more often than not the solver will begin taking care of without knowing the genuine issue. What the customer or client depicts as "The Problem" is ordinarily just the side effect! "My PC wouldn't like to turn on" is the indication. The genuine issue could be that the entire structure is without power. "Each time I attempt to include another item, I get a blunder message" is the manifestation. Here the genuine issue could be "Just the last 2 items I attempted to include gave an 'Item as of now exists' mistake". Another great model: "Nothing is working"...
You start your examination by characterizing the "genuine issue". This will involve posing inquiries (and once in a while confirm them), and doing some fundamental testing. Ask the client inquiries like "when was the last time it worked effectively?", "To what extent have you been utilizing the framework?", "Does it deal with another PC or another client?", "What is the precise mistake message?" and so on. Request a screen-print of the blunder if conceivable. Your essential testing will be to guarantee the start to finish gear is ready for action. Check the client's PC, the system, the Web Server, Firewalls, the File Server, the Database back-end, and so on. Best-case you will half quart point the issue as of now. In the most pessimistic scenarios, you can dispense with a lot of regions for the reason for the issue.
A genuine model. The manifestation as per the client: "The framework hangs up indiscriminately times when I spot orders". The earth: The client enters the request detail on a structure in a centralized computer application. At the point when all the detail is finished, the client will tab off the structure. The centralized server at that point sends this detail by means of correspondence programming to an Oracle Client/Server framework at the plant. The Oracle framework will do scope organization and either restores a blunder or a normal request go back to the centralized server framework. This issue is very genuine, on the grounds that you can free customers on the off chance that they attempt to place orders and the framework doesn't acknowledge them! To endeavor to tackle this issue, individuals began by examining: 1) The heap and limit of the centralized server equipment 2) Monitoring the system load between the centralized computer and the Oracle framework 3) Hiring advisors to investigate the correspondence programming 4) Debugging the Oracle scope quantification framework After putting in two or three months they couldn't take care of the issue.
The "Logical Problem Solver" was brought in. It took not exactly a day and the issue was unraveled! How? The solver goes through the day at the client to perceive what the "genuine issue" was. It was discovered that the issue just happens with fare orders. By examining the catch screen and client activities, it was discovered that with fare arranges the keep going field on the structure is constantly left clear and the client didn't tab off this field. The framework was not hanging, it trusted that the client will squeeze "tab" some other time. Issue comprehended. It tends to be noticed that the "Logical Problem Solver" had extremely constrained learning of the centralized computer, of the request catching framework, of the correspondence programming, and of the Oracle scope organization framework. Also, this brings us to Principle#2.
Standard #2. Try not to be reluctant to begin the unraveling procedure, regardless of whether you don't comprehend the framework.
How often have you heard "I can't contact that code, since it was created by another person!", or "I can't help since I am an HR Consultant and that is a Finance issue"? In the event that your clothes washer wouldn't like to turn on, you shouldn't be an Electrical Engineer, Washing Machine Repair Specialist, Technician, or whatever authority to do some fundamental deficiency finding. Ensure the fitting is working. Check the excursion switch, and so forth. "I have never observed this mistake" ought not to prevent you from endeavoring to unravel. With the blunder message and an Internet Search motor, you can get bunches of beginning stages.
In each intricate framework, there are two or three fundamental working standards. Framework A that peruses information from System B can be terribly mind-boggling (possibly a Laboratory Spectrometer that peruses information from a Programmable Logic Computer by means of an RS-232 port). Be that as it may, a few essentials to test for: Do the two frameworks have control? Is there a mistake message in the occasion sign on one of these frameworks? Can you "ping" or follow a system bundle from the one framework to the next? Attempt an alternate correspondence link. Quest the web for the mistake message.
When you have set up what the issue is, you have to begin fathoming it. Here and there the underlying examination will point you legitimately to the arrangement (switch the power on; supplant the broken link, and so forth). In any case, some of the time the genuine issue is unpredictable in itself, so the following rule is to fathom it basic.
Standard #3. Vanquish it basic.
We should begin this area with a genuine model. Under specific conditions, a put-away technique will hang. The put-away system typically takes about an hour to run (when it isn't hanging). Thus, the engineer attempted to troubleshoot. Roll out certain improvements and after that hold up one more hour or so to check whether the issue is settled. After certain days the engineer surrendered and the "Issue Solver" dominated. The "Issue Solver" had to his transfer the learning under which conditions the put-away technique would hang. Along these lines, it was a basic exercise to make a duplicate of the method, and after that with this duplicate to strip all pointless code. All parameters were changed with hard-coded values. Bits of code were executed at once and the outcome sets were, of course, hard-coded into the duplicate of the technique. Inside 3 hours the issue was explained. A vast circle was found.
What the "Issue Solver" did, was to recreate the issue and simultaneously attempted to confine the code that caused the issue. In doing as such, the complex (and tedious) put away methodology moved toward becoming something quick and basic.
On the off chance that the issue is inside an application, make another application and attempt to recreate the issue inside the new application as basic as could be expected under the circumstances. On the off chance that the issue happens when a specific strategy for a specific control gets called, at that point attempt to just incorporate this control in the unfilled application and call that technique with hard-coded values. On the off chance that the issue is with installed SQL inside a C# application, at that point attempt to reenact the SQL within a Database Query apparatus (like SQL*Plus for Oracle, Query Analyzer for SQL Server, or utilize the code in MS Excel by means of ODBC to the database).
The minute you can recreate the issue in a straightforward manner, you are over 80% on your approach to settle it.
On the off chance that you don't have the foggiest idea where in the program the issue is, at that point use DEBUG.
Rule #4. Troubleshoot.
Most application improvement apparatuses come standard with a debugger. Climate is Macromedia Flash, Microsoft Dot Net, Delphi, or whatever improvement condition there will be a type of debugger. On the off chance that the instrument doesn't come standard with a debugger, at that point you can reproduce one.
The principal thing you need to do with the debugger is to figure out where the issue is. You do this by including breakpoints at key zones. At that point, you run the program in troubleshooting mode and you will know between which breakpoints the issue happened. Drill down and you will discover the spot. Since you know where the issue is, you can "overcome it straightforward"
Another decent component of most debuggers incorporates the office to watch factors, values, parameters, and so on as you step through the program. With these qualities known at specific advances, you can hard-code them into your "rearranged form" of the program
On the off chance that an improvement device doesn't support troubleshooting, at that point, you can recreate it. Put in steps in the program that yields variable qualities and "hi I am here" messages either to the screen, to a long document, or to a database table. Make sure to take them out when the issue is settled... you don't need your document framework to be jumbled or topped off with log records!
Standard #5. There is an abundance of data on the database back-end that will tackle an issue.
The "Issue Solver" was called to help take care of a precarious issue. A venture was moving framework from a centralized server to customer server innovation. All went well during testing, yet when the frameworks went life, out of the blue there were many, and very arbitrary "General Protection Faults". (The GPF-blunder was the general mistake trap in Windows 95 and 98). It was attempted to disentangle the code, investigating endeavored, yet it was difficult to duplicate. In the LAB condition, the issue would not happen! Troubleshooting follows messages to log records demonstrated that the issue happened haphazardly. A few clients experienced it more than others, however, in the long run, all clients will get them! Intriguing issue.
How would you follow on the back-end database what's going on? The primary database suppliers have GUI devices that help you to follow or investigate what inquiries are terminated against the database. It will likewise demonstrate to you when individuals interface, disengage or were not able to associate on account of security infringement. Most databases likewise incorporate some framework word reference tables that can be questioned to get this data. These follow can now and again tell an entire story of why something is falling flat. The inquiry code you recover from the follow can be a help to "disentangle the pursuit". You can see from the following if the program reaches the database. You can perceive to what extent it takes for an inquiry to execute.
To add to Principle#2 (don't be hesitant to start...); you can investigate this follow data, despite the fact that you probably won't know anything about the detail of the application.
Keep in mind however that this back-end follows can put a strain toward the bank assets. Try not to leave them running for pointless long.
Standard #6. Utilize open-minded perspectives.
This is the last standard. Try not to invest an excessive amount of energy in the issue before you request help. The help doesn't need to be from somebody more senior than you. The guideline is that you need a couple of open-minded perspectives for a new point of view and now and again a touch of outside air by taking a break. The other individual will look and after that pose an inquiry or two. At times it is something evident that was missed. In some cases just by addressing the inquiry it makes you think in another way. Likewise, on the off chance that you go through hours taking a gander at a similar bit of code, it is extremely simple to begin looking once again a senseless mix-up. A great deal of account adjusting issues gets comprehended over a lager. It could be a difference in landscape, or potentially the casual climate that will fly out the arrangement. Perhaps it is the new oxygen that went to the cerebrum while strolling to the bar. Possibly it is on the grounds that the issue got talked about with another person.
End
In the wake of perusing this paper, the creator trust that you will attempt these whenever you experience an issue to unravel. Ideally, by applying these six standards you will understand the points of interest they bring, as opposed to "surmise" your way to an answer.
This paper will disclose a logical way to deal with critical thinking. In spite of the fact that it is composed to address Information Technology related issues, the ideas may likewise be relevant in different orders. The strategies, ideas, and systems portrayed here is the same old thing, yet it is stunning what number of "issue solvers" neglect to utilize them. In the middle of I will incorporate some genuine models.
For what reason do issue solvers surmise instead of following a logical way to deal with critical thinking? Possibly on the grounds that it feels snappier? Perhaps an absence of involvement in productive critical thinking? Or then again perhaps on the grounds that it feels like diligent work to do it deductively? Possibly while you continue speculating and not so much illuminating, you produce more salary and include some employer stability? Or then again perhaps on the grounds that you damage the main rule of critical thinking: comprehend the issue.Standard #1. Comprehend the *real* issue.
Is it safe to say that it isn't evident that before you can tackle, you have to comprehend the issue? Possibly. Yet, more often than not the solver will begin taking care of without knowing the genuine issue. What the customer or client depicts as "The Problem" is ordinarily just the side effect! "My PC wouldn't like to turn on" is the indication. The genuine issue could be that the entire structure is without power. "Each time I attempt to include another item, I get a blunder message" is the manifestation. Here the genuine issue could be "Just the last 2 items I attempted to include gave an 'Item as of now exists' mistake". Another great model: "Nothing is working"...
You start your examination by characterizing the "genuine issue". This will involve posing inquiries (and once in a while confirm them), and doing some fundamental testing. Ask the client inquiries like "when was the last time it worked effectively?", "To what extent have you been utilizing the framework?", "Does it deal with another PC or another client?", "What is the precise mistake message?" and so on. Request a screen-print of the blunder if conceivable. Your essential testing will be to guarantee the start to finish gear is ready for action. Check the client's PC, the system, the Web Server, Firewalls, the File Server, the Database back-end, and so on. Best-case you will half quart point the issue as of now. In the most pessimistic scenarios, you can dispense with a lot of regions for the reason for the issue.
A genuine model. The manifestation as per the client: "The framework hangs up indiscriminately times when I spot orders". The earth: The client enters the request detail on a structure in a centralized computer application. At the point when all the detail is finished, the client will tab off the structure. The centralized server at that point sends this detail by means of correspondence programming to an Oracle Client/Server framework at the plant. The Oracle framework will do scope organization and either restores a blunder or a normal request go back to the centralized server framework. This issue is very genuine, on the grounds that you can free customers on the off chance that they attempt to place orders and the framework doesn't acknowledge them! To endeavor to tackle this issue, individuals began by examining: 1) The heap and limit of the centralized server equipment 2) Monitoring the system load between the centralized computer and the Oracle framework 3) Hiring advisors to investigate the correspondence programming 4) Debugging the Oracle scope quantification framework After putting in two or three months they couldn't take care of the issue.
The "Logical Problem Solver" was brought in. It took not exactly a day and the issue was unraveled! How? The solver goes through the day at the client to perceive what the "genuine issue" was. It was discovered that the issue just happens with fare orders. By examining the catch screen and client activities, it was discovered that with fare arranges the keep going field on the structure is constantly left clear and the client didn't tab off this field. The framework was not hanging, it trusted that the client will squeeze "tab" some other time. Issue comprehended. It tends to be noticed that the "Logical Problem Solver" had extremely constrained learning of the centralized computer, of the request catching framework, of the correspondence programming, and of the Oracle scope organization framework. Also, this brings us to Principle#2.
Standard #2. Try not to be reluctant to begin the unraveling procedure, regardless of whether you don't comprehend the framework.
How often have you heard "I can't contact that code, since it was created by another person!", or "I can't help since I am an HR Consultant and that is a Finance issue"? In the event that your clothes washer wouldn't like to turn on, you shouldn't be an Electrical Engineer, Washing Machine Repair Specialist, Technician, or whatever authority to do some fundamental deficiency finding. Ensure the fitting is working. Check the excursion switch, and so forth. "I have never observed this mistake" ought not to prevent you from endeavoring to unravel. With the blunder message and an Internet Search motor, you can get bunches of beginning stages.
In each intricate framework, there are two or three fundamental working standards. Framework A that peruses information from System B can be terribly mind-boggling (possibly a Laboratory Spectrometer that peruses information from a Programmable Logic Computer by means of an RS-232 port). Be that as it may, a few essentials to test for: Do the two frameworks have control? Is there a mistake message in the occasion sign on one of these frameworks? Can you "ping" or follow a system bundle from the one framework to the next? Attempt an alternate correspondence link. Quest the web for the mistake message.
When you have set up what the issue is, you have to begin fathoming it. Here and there the underlying examination will point you legitimately to the arrangement (switch the power on; supplant the broken link, and so forth). In any case, some of the time the genuine issue is unpredictable in itself, so the following rule is to fathom it basic.
Standard #3. Vanquish it basic.
We should begin this area with a genuine model. Under specific conditions, a put-away technique will hang. The put-away system typically takes about an hour to run (when it isn't hanging). Thus, the engineer attempted to troubleshoot. Roll out certain improvements and after that hold up one more hour or so to check whether the issue is settled. After certain days the engineer surrendered and the "Issue Solver" dominated. The "Issue Solver" had to his transfer the learning under which conditions the put-away technique would hang. Along these lines, it was a basic exercise to make a duplicate of the method, and after that with this duplicate to strip all pointless code. All parameters were changed with hard-coded values. Bits of code were executed at once and the outcome sets were, of course, hard-coded into the duplicate of the technique. Inside 3 hours the issue was explained. A vast circle was found.
What the "Issue Solver" did, was to recreate the issue and simultaneously attempted to confine the code that caused the issue. In doing as such, the complex (and tedious) put away methodology moved toward becoming something quick and basic.
On the off chance that the issue is inside an application, make another application and attempt to recreate the issue inside the new application as basic as could be expected under the circumstances. On the off chance that the issue happens when a specific strategy for a specific control gets called, at that point attempt to just incorporate this control in the unfilled application and call that technique with hard-coded values. On the off chance that the issue is with installed SQL inside a C# application, at that point attempt to reenact the SQL within a Database Query apparatus (like SQL*Plus for Oracle, Query Analyzer for SQL Server, or utilize the code in MS Excel by means of ODBC to the database).
The minute you can recreate the issue in a straightforward manner, you are over 80% on your approach to settle it.
On the off chance that you don't have the foggiest idea where in the program the issue is, at that point use DEBUG.
Rule #4. Troubleshoot.
Most application improvement apparatuses come standard with a debugger. Climate is Macromedia Flash, Microsoft Dot Net, Delphi, or whatever improvement condition there will be a type of debugger. On the off chance that the instrument doesn't come standard with a debugger, at that point you can reproduce one.
The principal thing you need to do with the debugger is to figure out where the issue is. You do this by including breakpoints at key zones. At that point, you run the program in troubleshooting mode and you will know between which breakpoints the issue happened. Drill down and you will discover the spot. Since you know where the issue is, you can "overcome it straightforward"
Another decent component of most debuggers incorporates the office to watch factors, values, parameters, and so on as you step through the program. With these qualities known at specific advances, you can hard-code them into your "rearranged form" of the program
On the off chance that an improvement device doesn't support troubleshooting, at that point, you can recreate it. Put in steps in the program that yields variable qualities and "hi I am here" messages either to the screen, to a long document, or to a database table. Make sure to take them out when the issue is settled... you don't need your document framework to be jumbled or topped off with log records!
Standard #5. There is an abundance of data on the database back-end that will tackle an issue.
The "Issue Solver" was called to help take care of a precarious issue. A venture was moving framework from a centralized server to customer server innovation. All went well during testing, yet when the frameworks went life, out of the blue there were many, and very arbitrary "General Protection Faults". (The GPF-blunder was the general mistake trap in Windows 95 and 98). It was attempted to disentangle the code, investigating endeavored, yet it was difficult to duplicate. In the LAB condition, the issue would not happen! Troubleshooting follows messages to log records demonstrated that the issue happened haphazardly. A few clients experienced it more than others, however, in the long run, all clients will get them! Intriguing issue.
How would you follow on the back-end database what's going on? The primary database suppliers have GUI devices that help you to follow or investigate what inquiries are terminated against the database. It will likewise demonstrate to you when individuals interface, disengage or were not able to associate on account of security infringement. Most databases likewise incorporate some framework word reference tables that can be questioned to get this data. These follow can now and again tell an entire story of why something is falling flat. The inquiry code you recover from the follow can be a help to "disentangle the pursuit". You can see from the following if the program reaches the database. You can perceive to what extent it takes for an inquiry to execute.
To add to Principle#2 (don't be hesitant to start...); you can investigate this follow data, despite the fact that you probably won't know anything about the detail of the application.
Keep in mind however that this back-end follows can put a strain toward the bank assets. Try not to leave them running for pointless long.
Standard #6. Utilize open-minded perspectives.
This is the last standard. Try not to invest an excessive amount of energy in the issue before you request help. The help doesn't need to be from somebody more senior than you. The guideline is that you need a couple of open-minded perspectives for a new point of view and now and again a touch of outside air by taking a break. The other individual will look and after that pose an inquiry or two. At times it is something evident that was missed. In some cases just by addressing the inquiry it makes you think in another way. Likewise, on the off chance that you go through hours taking a gander at a similar bit of code, it is extremely simple to begin looking once again a senseless mix-up. A great deal of account adjusting issues gets comprehended over a lager. It could be a difference in landscape, or potentially the casual climate that will fly out the arrangement. Perhaps it is the new oxygen that went to the cerebrum while strolling to the bar. Possibly it is on the grounds that the issue got talked about with another person.
End
In the wake of perusing this paper, the creator trust that you will attempt these whenever you experience an issue to unravel. Ideally, by applying these six standards you will understand the points of interest they bring, as opposed to "surmise" your way to an answer.
Information Technology Problem Solving
Reviewed by Shakir Hussain
on
03:50
Rating:
Reviewed by Shakir Hussain
on
03:50
Rating:
No comments: