Maintaining Software: PC Technology - Report Example

Table of Contents Introduction 2 Components of the package 2 Performance of took kit 3 Testing 3 References 9 Introduction PC tool kit will ensure that the technical support individuals have a kit that suit needs in a single CD. Since it’s easier for them to carry a single set CD having all tools for detecting faults in PCs tools for management of both their physical and virtual environments, this will be the best kitty for a computer technician. This is particularly important since computer repair and faulty detection tool kit support each other. The purpose of the toolkit is to permit a technical support person to visit a faulty or improperly configured Windows PC and diagnose faults, tune the PC or recover data from it. The PC in question could be running either Windows 8 running on 32 bit architecture. The tool will have a collection software and utilities that available on but will formed into one kit that will provide the that can run from. Components of the package Maintaining several software is usually inefficient and sometimes a source of potential risk. Consolidation assists in removal of growth obstacles, minimize cost and complexity and optimize space and energy efficiency. Consolidation of packages and facilities also assist in removing redundancies, reducing application and storage sprawl, rationalizing operations and simplifying the daily maintenance and control of the whole system. The portable PC faulty detecting Utility Kit will have 7 recovery tools into one unit, providing PC software with easiness. The package can be installed from a CD directly so long the machine in question is has CD reader. The package will consist of the process explorer, CCleaner, PC Decrapifier, Firefox, 7 Zip PC Decrapifier - This will be responsible for uninstalling all trial software in the computer. It detects the software that ought to be removed from the PC and alerts the user to choose whether, one keeps them. Performance of took kit The most powerful weapon in your arsenal against faults is the ability to reason. There are also some hands techniques and tips that can reduce the time spent in detecting faults and bugs in PC. Some of the tool kits use techniques that apply the scientific method more efficiently. The PC tool kit will work with a PC that have no hardware errors that prevent it booting, you are not required to provide software that diagnoses hardware faults that prevent the post completing or result in the PC not being able to at least attempt to boot Windows. It has an antivirus package, and something to permanently erase files or recover lost data. This package will need specific requirements in terms of deployment and maintenance before usage. Testing Testing will include writing the conditions under which testing must occur and performing the actual tests. Depending on the success of the tests, the firm may decide to implement the project. Implementation would involve writing up detailed user instructions and documentation, determining optimum operational procedures and providing training for the program users. Maintenance strategy may also be included at this stage but may all the same come later as the program is put to proper use. Therein, help desks, procedures for program maintenance as well as favorable environments to support change if the latter should be necessary will also be spelt out. One will try to come up with the smallest amount of code that still exhibits the error. You can do this by removing calls to methods that are unnecessary and removing statements that should have no bearing on the problem. Anything one can do to reduce the complexity of the code for the package can be helpful. As one are removing code, should probably want to periodically run the code to make sure the fault or bug is still there. If it is discovered, the information can be used to reason about the cause of the error or faulty. As you remove code, be sure to retain a copy of the original code. Along these same lines, you should produce the smallest inputs that still cause the bug. If the program is interactive, try to find the shortest sequence of commands that cause the error to occur. Knowing the precise input that causes the problem is useful information. Bugs that occur sporadically are some of the hardest to track down. If the bug does not happen consistently, work to make the bug appear reliably. If the bug is a hard one to track down, you will probably be running the program over and over again. In this case, you want each run to be productive. How you make the bug appear reliably depends on the program; you will have to be resourceful. Here are some common techniques programmers use, depending on the situation determine the exact sequence of inputs or the precise conditions that cause the bug to occur. If you are using a random number generator, make sure the seed is set to the same value on each run. If the bug only occurs after the program has been running a long time. Figure out ways to simulate that behavior. Perhaps the bug only occurs when data structures grow large. Simulate this behavior by writing a function that builds large dummy data structures. Call the function at the beginning of the program to simulate the effect of the program running a long time. Try to determine what function or section of code is causing the problem. To do this, Print data values and observe at what point in the execution incorrect values are produced. It also helps to try different input values and observe the effect on the code. Sometimes with the right input you can “triangulate” the location of the error in the code. Locating a bug via triangulation often requires running a handful of test cases to narrow the location of the bug down to a region of code small enough to be helpful. The problem is that each test set may identify a large region of code. Consequently, more than two or three test cases are needed to zero in on the location of the bug. Explain the bug to someone else.- In the file stats example, explaining the code to someone else could have caught the error. Hopefully, the person you explain the code to has a different mindset or different mental model of what’s going on and will immediately see the problem that you were blind to. If you have worked at a help desk, you have probably experienced the phenomena known as “confessional debugging” a person is explaining the problem and as they do so, it suddenly dawns on them what the problem is. The act of explaining the code to someone makes you think a little more clearly, not skip steps, and on. Confessional debugging is surprisingly effective. Recompile everything. Modern IDEs are extremely useful, but sometimes they can get confused. If you have been making lots of changes to the code looking for a bug and the code is not behaving the way you think it should, or change you have made do not seem to be having an effect, rebuild the entire project from scratch and rerun the code. Gather more information. If you are stuck and cannot seem to understand what’s going on, generate more data. Some standard actions taken by experienced programmers include running different test cases, using the debugger to observe the program’s flow of execution, printing out intermediate results, and displaying data structures. You need to be selective and only print as much as you can reasonably digest. Sifting through mountains of data can be like searching for a needle in a haystack. Pay attention to the compiler. Modern compilers are very good at detecting certain types of errors. However, they tend to be conservative and sometimes produce warning messages that end up being spurious. When you are searching for a bug, it’s a good time to pay attention to all those warning messages you have been ignoring. If the compiler reports an object is used before being set, then that problem is something worth investigating. Many compilers allow the programmer to control the level at which error and warning messages are issued. Setting the compiler to the strictest level can sometimes yield information that is helpful in searching for a bug. Fix bugs as you find them. It often happens that when you are looking for a bug, you discover another bug. This bug seems unrelated to the bug you are trying to find. It is tempting to put off doing something about the bug just discovered since you are in the middle of tracking down the original bug. You do not want the trail to go cold. Generally, it is good practice to fix bugs as you find them. The bug you just found could be related to the one you were originally trying to find. Fixing this bug, could make the other bug go away. This phenomenon happens quite often. On the other hand, if you are sure the newly found bug is unrelated to the bug you were originally searching for, and then it may be worthwhile to keep searching. Take a break- Sometimes you get nowhere with a bug despite spending hours trying different strategies to locate it. While perseverance is a valuable programmer trait, knowing when to take a break and get away from a problem is also valuable. Experienced problem solvers know how important it is to get away and does something that lets the mind wander jog, listen to music, take a walk, and stare out the window, so on. As you relax, the solution to the problem might just come to you. Most experienced programmers have war stories about bug hunts. A common story is the “debugger`s epiphany.’’ The story goes something like this. Sally has been hunting a particularly nasty bug for days. None of the tried-and-true techniques for finding the bug have worked. Sally decides to take a break and hit the hills for some mountain biking action. When sally is flying down a hill with trees whizzing by, the last thing she is thinking about is the elusive bug in the web browser. After a great afternoon, sally heads home for a shower. As she showers, she starts to think about the bug again, and it hits her- the solution to the browser problem suddenly becomes crystal clear. Sally heads to work to run an experiment to validate her hypothesis, but she’s confident she’s got it. Stories like sallies are common- Of course, the best stories always have the programmer doing something unusual when the epiphany occurs! Think outside the box. It is very easy to get locked into a particular way of looking at or attacking a problem. If you are getting nowhere with a problem. Try thinking outside the box. Try something unusual or new that you have not tried before. For example, do the opposite of what you have been doing and see what happens. Debugging is an important part of the programming process. As you gain experience with programming, you will no doubt develop your own personal style of debugging favorite techniques, tricks, tools, and so forth. You will also learn to use a source-level debugger. A source-level debugger integrated into a modern IDE is a powerful tool for tracking down bugs. However, the most important point to remember is that the key to effective debugging is to follow a disciplined process. References Davis, L., 2009. Computer Repair Utility Kit You Can Run from a Thumb Drive. Available online from http://readwrite.com/2009/02/14/a_computer_repair_utility_kit#awesm=~oDlffUKUn0zytJ> [Accessed 05 May 2014]. Microsoft, 2014. Process Explorer v16.02. Available online from [Accessed 05 May 2014]. Pohjolaine, P., 2002. Software testing tools. Available online from [Accessed 05 May 2014]. StarTech.com, 2010. PC Repair Tools- Professional Network Installer Tool Kit. Available online from < http://content.etilize.com/user-manual/10055664.pdf>[Accessed 05 May 2014]. Klas, W. &  Schrefl, M., 1995. Metaclasses and Their Application: Data Model Tailoring and Database Integration. Berlin: Springer. Whitten, J. L. & Bentley, L, 2004. Systems Analysis and Design Methods. New York: McGraw-Hill/Irwin. Silverston, L., W.H.Inmon, W. & Kent Graziano, K., 1997. The Data Model Resource Book: A Library of Logical Data Models and Data Warehouse Designs. New York: John Wiley Read More