الصيانة: صيانة النظام
تغطي هذه الوحدة عملية صيانة نظم المعلومات، أنواع الصيانة وتكلفتها، وإدارة الصيانة بما في ذلك إدارة الأفراد وإدارة التكوين.
Maintenance: System Maintenance
This module covers the process of maintaining information systems, types and costs of maintenance, and managing maintenance including personnel and configuration management.
أهداف التعلم
- فهم عملية صيانة نظم المعلومات والخطوات المتضمنة فيها.
- التعرف على الأنواع المختلفة لصيانة النظام (التصحيحية، التكيفية، الكمالية، الوقائية).
- وصف العوامل التي تؤثر على تكلفة صيانة النظام وقابلية صيانته.
- فهم قضايا إدارة الصيانة بما في ذلك إدارة الأفراد، قياس الفعالية، وإدارة التكوين.
- Understand the process of maintaining information systems and its involved steps.
- Recognize the types of system maintenance (Corrective, Adaptive, Perfective, Preventive).
- Describe factors that influence the cost of system maintenance and maintainability.
- Understand maintenance management issues including personnel management, measuring effectiveness, and configuration management.
1 عملية صيانة النظام
1 System Maintenance Process
هي المرحلة الأطول والأكثر تكلفة في دورة حياة النظام، تبدأ فور تثبيت النظام وتتضمن تعديلات برمجية وإجرائية.
The longest and most expensive phase of the SDLC, starting immediately after installation, involving software and procedural changes.
تعتبر صيانة النظام أكبر نفقات تطوير النظم للعديد من المنظمات. تتضمن العملية أربع خطوات رئيسية: 1. الحصول على طلبات الصيانة (عبر عملية رسمية ووثائق). 2. تحويل الطلبات إلى تغييرات (تحليل النطاق والمخاطر). 3. تصميم التغييرات. 4. تنفيذ التغييرات. يجب على الإدارة تقييم المفاضلة بين الاستمرار في صيانة نظام قديم أو بناء/شراء نظام جديد.
System maintenance is the largest systems development expenditure for many organizations. The process involves four major activities: 1. Obtaining maintenance requests (via formal processes and documents). 2. Transforming requests into changes (analyzing scope, risk, and feasibility). 3. Designing changes. 4. Implementing changes. Management must constantly assess the trade-offs between maintaining an older system and developing a new one.
القرار المالي بإيقاف نظام قديم يعتمد على تكلفة الصيانة المتزايدة مقابل العائد من النظام الجديد. دورة الصيانة تشبه دورة حياة تطوير النظم (SDLC) مصغرة، حيث يمر كل طلب تغيير بمراحل التخطيط، التحليل، التصميم، والتنفيذ.
The financial decision to discontinue an older system depends on the escalating costs of maintenance versus the ROI of a new system. The maintenance cycle acts as a miniature SDLC, where each change request loops through planning, analysis, design, and implementation phases.
متى يكون من المنطقي مالياً التوقف عن صيانة نظام قديم وبناء نظام جديد؟ At what point does it make financial sense to discontinue evolving an older system and build a new one?
عندما تتجاوز تكلفة الصيانة (بسبب ضعف قابلية الصيانة وتراكم العيوب) تكلفة تطوير نظام جديد، أو عندما لا يعود النظام قادراً على تلبية احتياجات العمل الأساسية.
When the cost of maintenance (due to low maintainability and accumulated defects) exceeds the cost of developing a new system, or when the system can no longer adapt to core business needs.
2 أنواع الصيانة
2 Types of Maintenance
تنقسم الصيانة إلى أربعة أنواع: تصحيحية (لإصلاح الأخطاء)، تكيفية (للتكيف مع التغييرات)، كمالية (لإضافة ميزات)، ووقائية (لمنع الفشل المستقبلي).
Maintenance is divided into four types: Corrective (fixing bugs), Adaptive (adapting to changes), Perfective (adding features), and Preventive (avoiding future failures).
1. الصيانة التصحيحية: إصلاح عيوب التصميم أو البرمجة. تمثل 75% من نشاط الصيانة، وهي عاجلة ولكنها لا تضيف قيمة جديدة.
2. الصيانة التكيفية: تعديل النظام لتلبية احتياجات العمل المتغيرة أو بيئات التشغيل الجديدة.
3. الصيانة الكمالية: تحسين الأداء أو واجهة المستخدم أو إضافة ميزات جديدة (تعتبر تطويراً جديداً تقريباً).
4. الصيانة الوقائية: إجراء تغييرات لتقليل احتمالية فشل النظام في المستقبل (أقل أولوية).
1. Corrective maintenance: Repairing design, coding, or implementation errors. It accounts for 75% of maintenance activity, is typically urgent, but adds no new value.
2. Adaptive maintenance: Modifying the system to evolve functionality or migrate to a different environment.
3. Perfective maintenance: Making enhancements to improve performance, usability, or add features (often resembles new development).
4. Preventive maintenance: Safeguarding the system from future problems (lowest priority).
النسبة العالية للصيانة التصحيحية (75%) تشير غالباً إلى ضعف في مرحلتي الاختبار والتصميم الأولي. المنظمات الناضجة تسعى لتقليل الصيانة التصحيحية لزيادة الموارد المتاحة للصيانة التكيفية والكمالية التي تضيف قيمة حقيقية للعمل.
The high percentage of corrective maintenance (75%) often indicates inadequacies in the initial testing and design phases. Mature organizations strive to reduce corrective maintenance to free up resources for adaptive and perfective maintenance, which actually add business value.
| Corrective | Adaptive | Perfective | Preventive | |
|---|---|---|---|---|
| الهدف الأساسيPrimary Goal | إصلاح الأخطاءFix errors | التكيف مع التغييراتAdapt to changes | إضافة ميزات/تحسينAdd features/improve | منع الفشل المستقبليPrevent future failure |
| إضافة قيمة للعملAdds Business Value | لاNo | نعمYes | نعم (تطوير جديد)Yes (New dev) | نعم (استقرار)Yes (Stability) |
| الأولوية / الاستعجالPriority / Urgency | عاجل جداًVery Urgent | أقل استعجالاًLess Urgent | مجدولScheduled | أقل أولويةLowest Priority |
لماذا تعتبر الصيانة التصحيحية 'لا تضيف قيمة' رغم أهميتها القصوى؟ Why is corrective maintenance considered to 'add no value' despite being highly urgent?
لأنها تعيد النظام فقط إلى الحالة التي كان ينبغي أن يكون عليها منذ البداية، ولا تقدم ميزات أو قدرات جديدة للمستخدمين.
Because it merely restores the system to the state it was originally supposed to be in, without introducing any new features or capabilities for the users.
3 التكلفة وقابلية الصيانة
3 Cost and Maintainability
تستهلك الصيانة 60-80% من ميزانية النظم. قابلية الصيانة هي سهولة فهم وتصحيح وتعديل البرنامج.
Maintenance consumes 60-80% of IS budgets. Maintainability is the ease with which software can be understood, corrected, adapted, and enhanced.
تخصص المنظمات 60% إلى 80% من ميزانية نظم المعلومات للصيانة، ويعمل 52% من المبرمجين في صيانة النظم الداخلية. قابلية الصيانة تتأثر بعدة عوامل رئيسية: 1. عدد العيوب الكامنة (الأخطاء غير المكتشفة). 2. عدد العملاء (زيادة العملاء تزيد التكلفة). 3. جودة التوثيق (بدون توثيق جيد، تزداد جهود الصيانة بشكل أسي). عوامل أخرى تشمل الأفراد، الأدوات، وهيكلة البرمجيات.
Organizations allocate 60% to 80% of their IS budget to maintenance, with 52% of programmers assigned to maintain in-house systems. Maintainability is influenced by key factors: 1. Number of latent defects (unknown errors). 2. Number of customers (more customers = higher costs). 3. Documentation quality (poor documentation exponentially increases maintenance effort). Other factors include personnel, tools, and software structure.
العلاقة بين جودة التوثيق وجهد الصيانة ليست خطية بل أسية. التوثيق الضعيف يعني أن المبرمجين يقضون وقتاً طويلاً في 'الهندسة العكسية' العقلية لفهم الكود قبل إجراء أي تغيير، مما يزيد من احتمالية إدخال أخطاء جديدة (تأثير التموج).
The relationship between documentation quality and maintenance effort is exponential, not linear. Poor documentation forces programmers to spend excessive time mentally 'reverse-engineering' the code before making changes, which drastically increases the risk of introducing new bugs (ripple effect).
كيف يؤثر عدد العملاء على تكلفة الصيانة؟ How does the number of customers affect maintenance costs?
كلما زاد عدد العملاء، زادت بيئات التشغيل المختلفة، وزادت التبليغات عن الأخطاء، وتنوعت طلبات الميزات الجديدة، مما يرفع التكلفة الإجمالية للدعم والصيانة.
More customers mean more diverse operating environments, a higher volume of bug reports, and a wider variety of feature requests, all of which drive up support and maintenance costs.
4 إدارة أفراد الصيانة
4 Managing Maintenance Personnel
يمكن تنظيم فرق الصيانة بثلاث طرق: فريق منفصل، فريق مدمج (نفس المطورين)، أو فريق وظيفي (يتبع للمستخدمين النهائيين).
Maintenance teams can be organized in three ways: Separate group, Combined group (same developers), or Functional group (within end-user units).
بما أن الصيانة تستحوذ على الجزء الأكبر من المبرمجين، فإن إدارتهم حاسمة. هناك 3 هياكل تنظيمية:
1. منفصل (Separate): فريق صيانة مستقل. يحسن جودة التوثيق (بسبب النقل الرسمي) لكن الفريق قد يفتقر لمعلومات غير موثقة.
2. مدمج (Combined): نفس من بنى النظام يصونه. يعرفون كل الافتراضات، لكن التوثيق قد يضعف لعدم وجود نقل رسمي.
3. وظيفي (Functional): موظفو الصيانة يتبعون لوحدات العمل (المستخدمين). فهم ممتاز للمتطلبات، لكن قد يفتقرون للموارد التقنية والتنقل الوظيفي.
Since maintenance is the largest segment of programming personnel, managing them is critical. There are 3 organizational structures:
1. Separate: A distinct maintenance group. Improves documentation quality (due to formal handoffs) but the group may lack undocumented critical info.
2. Combined: The developers who built the system also maintain it. They know all assumptions, but documentation may suffer due to lack of formal handoff.
3. Functional: Maintenance personnel reside in the business units. They have a vested interest and understand requirements well, but may lack technical resources and job mobility.
اختيار الهيكل يعتمد على ثقافة المنظمة. الهيكل المنفصل يجبر المنظمة على تبني ممارسات هندسة برمجيات صارمة (توثيق قوي)، بينما الهيكل المدمج يعتمد على المعرفة القبلية (Tribal Knowledge) التي تشكل خطراً إذا غادر الموظفون.
Choosing a structure depends on organizational culture. A separate structure forces strict software engineering practices (strong documentation), whereas a combined structure relies heavily on tribal knowledge, posing a significant risk if key developers leave.
| Separate | Combined | Functional | |
|---|---|---|---|
| جودة التوثيقDocumentation Quality | عالية (بسبب النقل الرسمي)High (Formal handoff) | منخفضةLow | متوسطةMedium |
| معرفة النظام العميقةDeep System Knowledge | قد تفتقر للمعلومات غير الموثقةMay lack undocumented info | ممتازة (هم من بنوا النظام)Excellent (Built the system) | فهم ممتاز لمتطلبات العملExcellent business understanding |
لماذا قد يؤدي دمج فريق التطوير والصيانة إلى ضعف التوثيق؟ Why might combining the development and maintenance teams lead to poor documentation?
لأن المطورين يعتمدون على ذاكرتهم وفهمهم العميق للنظام، فلا يشعرون بالحاجة الملحة لكتابة توثيق مفصل لنقل المسؤولية لجهة أخرى.
Because developers rely on their memory and deep understanding of the system, feeling less urgency to write detailed documentation since there is no formal handoff to another team.
5 قياس الفعالية والتحكم في الطلبات
5 Measuring Effectiveness and Controlling Requests
تقاس الفعالية بمتوسط الوقت بين الأعطال (MTBF). ويتم التحكم في الطلبات عبر تقييمها وتصنيفها لتحديد الأولويات.
Effectiveness is measured by Mean Time Between Failures (MTBF). Requests are controlled by evaluating and prioritizing them based on criticality.
قياس الفعالية: يعتمد على 3 عوامل: عدد الأعطال، الوقت بين الأعطال، ونوع العطل. المقياس الأهم هو MTBF (متوسط الوقت بين الأعطال)، والذي يجب أن يزداد بمرور الوقت بعد تثبيت النظام.
التحكم في الطلبات: ليس كل طلب يتم تنفيذه. تمر الطلبات بمسار: استلام الطلب -> تحديد نوعه (تصحيحي، تكيفي، الخ) -> تقييمه -> إذا كان ضرورياً يتم تصنيفه وتحديد أولويته -> إضافته لقائمة المهام.
Measuring Effectiveness: Based on 3 factors: Number of failures, Time between each failure, and Type of failure. The key metric is MTBF (Mean Time Between Failures), which should increase over time after installation.
Controlling Requests: Not all requests are performed. The flow is: Receive request -> Determine type (Corrective, Adaptive, etc.) -> Evaluate -> If needed, categorize and prioritize -> Select next task from queue.
انخفاض MTBF بمرور الوقت هو مؤشر خطير يدل على أن النظام يتدهور (Software Entropy) وأن التعديلات السابقة ربما أدخلت أخطاء جديدة، مما يستدعي إعادة هندسة النظام أو استبداله.
A decreasing MTBF over time is a critical warning sign of software entropy, indicating that recent maintenance changes are introducing new bugs. This often triggers the decision to re-engineer or replace the system.
ماذا يعني إذا كان منحنى MTBF مسطحاً (لا يرتفع ولا ينخفض) بعد عدة أشهر من إطلاق النظام؟ What does it mean if the MTBF curve is flat (neither rising nor falling) several months after system launch?
يعني أن معدل اكتشاف وإصلاح الأخطاء يساوي معدل ظهور أخطاء جديدة، مما يشير إلى استقرار نسبي ولكن دون تحسن في جودة النظام الأساسية.
It means the rate of fixing bugs equals the rate of discovering new ones, indicating a steady state but no underlying improvement in system quality.
6 إدارة التكوين
6 Configuration Management
هي حارس البوابة للكود؛ تضمن عدم إجراء أي تغييرات غير مصرح بها باستخدام أدوات التحكم في الإصدارات.
The gatekeeper of code; it ensures only authorized changes are made using version control tools.
إدارة التكوين هي عملية ضمان إجراء التغييرات المصرح بها فقط على النظام.
الوحدة الأساسية (Baseline module): هي وحدة برمجية تم اختبارها وتوثيقها والموافقة على تضمينها في أحدث إصدار.
أمين مكتبة النظام (System librarian): يتحكم في عمليات سحب وإيداع (check-out / check-in) الكود المصدري.
تستخدم أدوات مثل التحكم في المراجعة (تجميد ملفات معينة) والتحكم في الكود المصدري (تتبع التغييرات وإعادة بناء الإصدارات السابقة).
Configuration Management is the process of ensuring that only authorized changes are made to a system.
Baseline module: A software module that has been tested, documented, and approved to be included in the most recently created version of a system.
System librarian: Controls the checking out and checking in of baseline source code modules.
Tools include revision control (freezing specific files) and source code control (tracking changes and rebuilding historic versions).
بدون إدارة التكوين، يمكن لمبرمجين اثنين تعديل نفس الملف في نفس الوقت، مما يؤدي إلى الكتابة فوق عمل بعضهما البعض. أدوات التحكم في الكود المصدري (مثل Git حديثاً) تمنع ذلك وتسمح بالتتبع الدقيق لكل سطر كود (من كتبه ولماذا).
Without configuration management, two programmers might modify the same file simultaneously, overwriting each other's work. Source code control tools prevent this and allow granular traceability of every line of code (who wrote it and why).
ما الفرق بين التحكم في المراجعة (Revision control) والتحكم في الكود المصدري (Source code control)؟ What is the difference between revision control and source code control?
التحكم في المراجعة يركز على تجميد أو قفل ملفات محددة لمنع التعديل، بينما التحكم في الكود المصدري يمتد ليشمل تتبع التغييرات عبر ملفات مترابطة وإمكانية إعادة بناء إصدارات تاريخية كاملة.
Revision control focuses on freezing or locking specific files to prevent modification, while source code control extends to tracking interrelated files and facilitating the rebuilding of entire historic versions of the system.
7 الأدوات الآلية وصيانة المواقع
7 Automated Tools and Website Maintenance
تستخدم أدوات الهندسة العكسية لفهم الكود القديم، بينما تتطلب صيانة المواقع إبقاء الموقع متاحاً 24/7 مع فحص الروابط المكسورة.
Reverse engineering tools help understand old code, while website maintenance requires 24/7 uptime and checking for broken links.
الأدوات الآلية:
- أدوات الهندسة العكسية: تقرأ الكود المصدري وتنشئ تمثيلاً تصميمياً له (مفيدة للأنظمة القديمة غير الموثقة).
- أدوات إعادة الهندسة: تقوم بتعديل النظام الحالي تلقائياً لتحسين جودته أو أدائه.
صيانة المواقع الإلكترونية:
يجب أن تكون المواقع متاحة 24/7/365. يتم إجراء الصيانة دون إيقاف الموقع بالكامل (قفل صفحات معينة بوضع إشعار 'خارج الخدمة مؤقتاً'). تشمل المهام: فحص الروابط المكسورة (باستخدام أدوات مثل LinkAlarm)، التحقق من صحة HTML، وإعادة التسجيل في محركات البحث عند تغيير المحتوى بشكل كبير.
Automated Tools:
- Reverse engineering tools: Create a design-level representation from existing code (crucial for undocumented legacy systems).
- Re-engineering tools: Automatically alter an existing system to improve its quality or performance.
Website Maintenance:
Websites must be available 24/7/365. Maintenance is done without taking the whole site offline (locking specific pages with 'Temporarily Out of Service' notices). Tasks include: checking for broken links (e.g., LinkAlarm), HTML validation, and reregistering with search engines when content changes significantly.
الهندسة العكسية لا تغير النظام، بل تستخرج المعرفة منه. إعادة الهندسة تغير النظام فعلياً. في صيانة الويب، التغييرات المستمرة قد تربك الزوار الدائمين، لذا يجب موازنة التحديثات مع استقرار تجربة المستخدم (UX).
Reverse engineering does not change the system; it extracts knowledge. Re-engineering actively changes the code. In web maintenance, constant UI changes can confuse frequent visitors, so updates must be balanced with User Experience (UX) stability.
لماذا يجب إعادة تسجيل الموقع في محركات البحث بعد إجراء صيانة كبيرة؟ Why should a website be reregistered with search engines after major maintenance?
لأن التغييرات الكبيرة في المحتوى أو الهيكلة قد تؤدي إلى فقدان الموقع لترتيبه في نتائج البحث إذا لم تقم محركات البحث بفهرسة المحتوى الجديد بشكل صحيح.
Because significant changes in content or structure might cause the site to lose its search ranking if search engines do not properly index the new, updated content.