--- title: "Software maintenance and fixing common bugs" subject: "Instrumentation II" chapter: 9 key: "semester_5/instrumentation_ii:sw-maintenance-bugs" source: https://www.bctengineer.com/q/semester_5/instrumentation_ii/sw-maintenance-bugs site: BCT Engineering --- # Software maintenance and fixing common bugs Instrumentation II · Chapter 9: Software For Instrumentation And Control Applications - Asked in: 2070 Chaitra, 8 marks - Answer checked by Claude Sonnet 5.5 on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_5/instrumentation_ii/sw-maintenance-bugs - Whole chapter: https://www.bctengineer.com/md/semester_5/instrumentation_ii/chapter-9 ## Question Once you have tested, verified and release software, you have to maintain it. As with testing, you cannot separate software maintenance from system concerns. Discuss at length how you get common bugs in software and develop a good corrective action to fix software bugs in your distributed software. ## Short answer In distributed software, bugs arise from design errors, concurrency issues (race conditions, deadlocks), communication faults, and version mismatches. Corrective action: record and reproduce the bug, isolate root cause, design a minimal fix, test thoroughly including regression, deploy with version control, and update documentation. ## Answer #### How bugs arise in a (distributed) software system Maintenance is the work done after release to correct faults, adapt to new environments, and improve the product. In distributed software, bugs come from: 1. **Requirement and design errors** that testing did not find. 2. **Coding errors:** logic, boundary, memory and data-type mistakes. 3. **Concurrency and timing problems:** race conditions, deadlocks and synchronisation errors between nodes. 4. **Communication faults:** message loss, delay, ordering, network failures, and protocol or data-format mismatch. 5. **Integration and version mismatch** between modules or nodes, and configuration or environment differences (OS, hardware, library). 6. **Changes made during maintenance** that introduce new bugs (regression), and poor documentation. 7. **Unexpected loads and inputs** in the field, and resource exhaustion. #### Developing a good corrective action 1. **Report and record** the problem in a bug-tracking system, with the steps to reproduce it, logs, version, severity and priority. 2. **Reproduce and isolate** the problem using logs, debuggers and tracing across nodes; identify the module and the root cause (not just the symptom). 3. **Analyse the impact** on other modules and nodes before changing anything. 4. **Design and implement the fix** with the smallest possible change, following the coding standards, and then review the code. 5. **Test:** test the fix, run the regression tests, and test in a staging environment that duplicates the distributed set-up. 6. **Controlled release:** use version control and configuration management; deploy as a patch (rolling update) with a roll-back plan. 7. **Update the documentation** and inform the users. 8. **Preventive actions:** analyse the cause to find similar defects, improve tests and processes, add monitoring and logging, and carry out periodic maintenance. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. Which bug is specific to distributed software? A. Compiler typos B. Message loss, delay and ordering faults C. Hardware wear only D. Paper documentation Answer: B. Communication faults arise between nodes. (Key point: Distributed bugs) 2. In corrective action, what should be identified? A. Only the symptom B. The tester's name C. The root cause, not just the symptom D. Nothing before patching Answer: C. Fix the cause. (Key point: Root cause) 3. Why run regression tests after a fix? A. To delay release B. To remove documentation C. To avoid staging D. To check the fix has not broken existing features Answer: D. Changes can introduce new bugs. (Key point: Regression) 4. What should accompany a patch deployment? A. A roll-back plan using version control B. No plan C. Deleting old versions D. Immediate full deployment Answer: A. Controlled release includes roll-back. (Key point: Controlled release) ## Related in Instrumentation II - [Software bugs and testing techniques](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Abug-types-testing) — Instrumentation II, chapter 9, asked 2× - [Software testing time paradox](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Asw-testing-paradox) — Instrumentation II, chapter 9 - [Phases of introduction of bugs in software](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Abugs-introduction) — Instrumentation II, chapter 9, asked 2× - [Good programming practice and software selection](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Agood-programming-software-selection) — Instrumentation II, chapter 9, asked 2× - [Nature of bugs and preventive steps](https://www.bctengineer.com/question.md?key=semester_5%2Finstrumentation_ii%3Abugs-prevent) — Instrumentation II, chapter 9, asked 2× ## Related in other subjects - [Preventive maintenance is better than corrective](https://www.bctengineer.com/question.md?key=semester_8%2Fconstruction_management%3Apreventive-better-than-corrective) — Construction Management, chapter 9, asked 4× - [Preventive, corrective and breakdown maintenance](https://www.bctengineer.com/question.md?key=semester_8%2Fconstruction_management%3Apreventive-vs-corrective-define) — Construction Management, chapter 9, asked 3× - [Component, integration and release testing](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Acomponent-release-integration) — Software Engineering, chapter 8 - [Software maintenance and its types](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Amaintenance-types) — Software Engineering, chapter 10