نظام حضور وانصراف خاص_ نقاش

[ابوخليل]

السلام عليكم

سأعرض الفكرة باختصار غير مخل :

التاريخ والوقت المدخل نوع التنسيق جنرال 

العملية مفتوحة .. التوقيع الأول = حضور والذي يليه انصراف .. ثم الذي يليه حضور ثم انصراف

بمعنى ان العملية مفتوحة بغير وقت محدد ، فيمكن للموظف ان يوقع حضور  وانصراف 10 مرات في اليوم او اكثر 

بل ان اليوم غير موجود في القاموس حيث ان العملية تبقى مستمرة  فقد يوقع الساعة العاشرة مساء ويخرج السادسة صباحا من الغد

بشرط وجود ضابط صغير  ( انتظار دقيقة او اكثر بين كل توقيعين ) من اجل تلافي الخطأ الغير مقصود

الآن :

هل اعمل جدول حضور وانصراف يحتوي على ثلاث حقول : المعرف / وقت الحضور/ وقت الانصراف

ام  جدولا يحتوي على المعرف / وحقلا واحد يشمل الحضور والانصراف معا ( اي ان كل عملية بسجل مستقل )

ابعاد العملية هي التي تشحذ الفكر وتعطي تصورا صحيحا

المخرجات المطلوبة :  حصر ساعات العمل

 

 

[Foksh]

وعليكم السلام ورحمة الله وبركاته ,,

بنظري وما أعتقده أن الفكرة الثانية أفضل ، حيث أنه يتوافق تماماً مع طلبك ( توقيعات مفتوحة ومتعددة ) ..

ولضبط فكرة أن كل حضور سيتبعه انصراف ، فقد نحتاج لحقل يكون بمثابة بصمة رقمية أو نصي ( حسب نمط البصمة أو الجلسة على اعتبار ان كل حضور وانصراف = جلسة ) .

والهدف منه هو ربط كل توقيع حضور مع توقيع الانصراف المقابل له بشكل منظم .

وكتصور للفكرة ..

• سأفترض أننا أضفنا حقلاً نصياً اسمه على سبيل المثال = SessionID ؛ وستكون قيمته فرضاً وليس حصراً ( EmployeeID_Date_SequenceNumber ) .
  وأيضاً كنوع من تحديد الحركة ، سنضيف حقل ActionType = نصي ، مهمته ستكون تحديد نوع الحركة ( CheckIn / CheckOut )
• لنفترض أن الموظف E123 يريد تسجيل حضور اليوم = 21-6-2025 ، هذا يعني ان قيمة الحقل ستكون = E123_20250621_1 . والقيمة للحقل ActionType = CheckIn .
  الآن عند تسجيل الإنصراف ستكون الحركة التالية = E123_20250621_1 . والقيمة للحقل ActionType = CheckOut . وهنا ستكون البصمة أو الجلسة مرتبطة بالرقم E123_20250621_1 لها حركتين ( CheckIn / CheckOut ) .

اعلم أن الفكرة كتصور قد تكون غير واضحة بشكل كافي ، ولكن برأيي ستمكنك هذه الفكرة من سهولة تتبع كل بصمة أو جلسة ( حضور / انصراف ) لأي موظف . أضف إلى ذلك أنك تستطيع هنا ضبط وحساب دقيق لساعات العمل لكل جلسة لكل موظف . وأيضاً كنوع من ضبط وكشف الجلسات المفتوحة ( التي تم فيها تسجيل حضور بدون انصراف ) .

 

وقد تتوسع الفكرة بشكل كبير حسب الإمكانيات المتاحة والمتطلبات 😅 . ولكني سأقتصر على ما ذكرته سابقاً .

[ابوخليل]

24 دقائق مضت, Foksh said:

 

بنظري وما أعتقده أن الفكرة الثانية أفضل 

 

هذا هو المعمول به في مكائن الحضور والانصراف المنتشرة

آي دي /  حقل للتاريخ والوقت / حقل لنوع التوقيع

غالبا يستخدمون حرف نصي : ( O ) و ( I )

................

ولكن اذا استخدمنا حقلين اصبح استخراج فرق التوقيت  سهلا جدا

......................

سأعرض تصوري للفكرة الأولى .. وفيها اشكالية لو تم حلها فسيصبح التصور مقبولا

الضابط في الفكرة : استعلام مصدره جدول الحضور المعيار هو معرف الموظف يعرض سجلا واحدا هو عبارة عن اكبر سجل في الجدول (مفتاح الجدول )

الآن يوجد ثلاث احتمالات :

اما ان يكون هذا اول توقيع للموظف ... ستكون النتيجة = صفر  هنا نفتح سجل جديد .. ونسجل في حقل الحضور

واما ان يظهر السجل .. حقل الحضور ( نعم ) و حقل الانصراف (فارغ) .. هنا ندخل التوقيع في الحقل الفارغ

وإما ان يظهر الحقلين ( نعم)  ... اقصد بنعم اي تحتوي على بيانات ( تاريخ) .. هنا نفتح سجل جديد .. ونسجل في حقل الحضور

الآن الصورة واضحة ويمكننا من خلال هذه الاحتمالاات تسجيل التوقيع في المكان المناسب

بقي امامي اشكالية !!!

ماذا لو لم يتم توقيع الانصراف الا بعد يومين او ثلاثة ...  هل من فكرة لتجنب هذه الثغرة ؟

على اعتبار  اننا سنلغي ضابط اليوم المحدد

[ابوخليل]

قد يخطر على البال تحديد اكبر فترة ممكنة لبقاء العامل  في عمله .. واذا تجاوزها ثم قام بالتوقيع  يسجل له في حقل الانصراف غياب 

ويخبره ان توقيعه خارج النظام  .. ويمكنه تسجيل الحضور الجديد

 

[Foksh]

4 دقائق مضت, ابوخليل said:

الضابط في الفكرة : استعلام مصدره جدول الحضور المعيار هو معرف الموظف يعرض سجلا واحدا هو عبارة عن اكبر سجل في الجدول (مفتاح الجدول )

 

سيكون هنا حاجة لإضافة شرط تحققي من تاريخ السجل بما أنه سيجلب أكبر سجل ( مفتاح الجدول ) المقرون برقم الموظف طبعاً . فإحتمالية تسجيل الحضور الأخير لم يتبعه تسجيل إنصراف !!!! وبالتالي سيكون الشرط هو البحث عن آخر جلسة غير مكتملة ( دون إنصراف ) . وهذا ما تسائلتم به في نهاية مشاركتكم ,,

11 دقائق مضت, ابوخليل said:

ماذا لو لم يتم توقيع الانصراف الا بعد يومين او ثلاثة ...  هل من فكرة لتجنب هذه الثغرة ؟

على اعتبار  اننا سنلغي ضابط اليوم المحدد

ولكن قد يكون هناك فكرة لتحديد حد زمني محدد للجلسة ( مثلاً 12 ساعة عمل ) . أي أن الجلسة التي تتجاوز هذا الحد تغلق تلقائياً في نهاية اليوم ، وذلك يمكن من خلال إضافة حقل Auto_Closed ، للتمييز بين الجلسات المغلقة يدوياً وتلك المغلقة آلياً .

أو كفكرة ثانية وقد تكون غير مرجحة ، وهي انه عند تسجيل حضور جديد وتم الكشف عن جلسة مفتوحة لم يتم اغلاقها مدتها أكبر من 24 ساعة على سبيل المثال ، يتم اغلاقها تلقائياً قبل فتح سجل جلسة جديدة !!!!

 

11 دقائق مضت, ابوخليل said:

قد يخطر على البال تحديد اكبر فترة ممكنة لبقاء العامل  في عمله .. واذا تجاوزها ثم قام بالتوقيع  يسجل له في حقل الانصراف غياب 

ويخبره ان توقيعه خارج النظام  .. ويمكنه تسجيل الحضور الجديد

 

صدقاً .. قد جاء ردي دون قراءة ردكم  😯

[Foksh]

27 دقائق مضت, ابوخليل said:

قد يخطر على البال تحديد اكبر فترة ممكنة لبقاء العامل  في عمله .. واذا تجاوزها ثم قام بالتوقيع  يسجل له في حقل الانصراف غياب 

ويخبره ان توقيعه خارج النظام  .. ويمكنه تسجيل الحضور الجديد

تعني أنه إذا كانت الجلسة المفتوحة أقل من 24 ساعة على سبيل المثال ، فيتم عرض تنبيه للمستخدم :-

" يوجد جلسة مفتوحة من ( التاريخ والوقت ) . هل تريد إغلاقها وبدء جلسة جديدة ؟ "

بحيث يختار إما :-

إغلاق الجلسة السابقة وبدء جديدة

أو إلغاء العملية والباقاء على الجلسة السابقة على سبيل المثال ؟؟؟

 

وهنا أعتقد قد تكون لنا حاجة للوحة مدير بحيث يتم توسيع الأفكار ومنح هذا السجل بالتجاوز عنه من الإغلاق الآلي ... إلخ من صلاحيات أو أفكار  

 

هنا الموضوع قد توسع في مخيلتي 😁 .

[ابوخليل]

26 دقائق مضت, Foksh said:

صدقاً .. قد جاء ردي دون قراءة ردكم  😯

تلاقح افكار .. على قولتهم احنا بالهوى سوى

26 دقائق مضت, Foksh said:

 

أو كفكرة ثانية وقد تكون غير مرجحة ، وهي انه عند تسجيل حضور جديد وتم الكشف عن جلسة مفتوحة لم يتم اغلاقها مدتها أكبر من 24 ساعة على سبيل المثال ، يتم اغلاقها تلقائياً قبل فتح سجل جلسة جديدة !!!!

 

هذا لا يمكن

لا يمكن فتح سجل جديد .. مادام  حقل الانصراف فارغ

لو جاء بعد شهر  ( حسب وضع معيار حد زمني ) ثم وقع .. فسيقوم باغلاق الحقل كما يحدده النظام .. ثم يفسح له المجال لتسجيل جديد

كل هذا سيتم آليا من غير تدخل

انا كتبت لصاحب العمل اذا يمكن تحديد اقصى فترة

يبدوا ان العمال ينامون في المنشأة اثناء العمل 

[Foksh]

2 دقائق مضت, ابوخليل said:

هذا لا يمكن

لا يمكن فتح سجل جديد .. مادام  حقل الانصراف فارغ

لو جاء بعد شهر  ( حسب وضع معيار حد زمني ) ثم وقع .. فسيقوم باغلاق الحقل كما يحدده النظام .. ثم يفسح له المجال لتسجيل جديد

كلام سليم 100% .. ومن هنا خطرت لي فكرة لوحة تحكم للمشرف أو المدير . حيث يتم عرض جميع الجلسات المفتوحة التي تجاوزت المدة المقررة ولنفترض 24 ساعة ، ومنحه إمكانية إغلاقها يدوياً مع إضافة تعليق كملاحظة على سبيل المثال . وسيكون من السهل إحصاء عدد المرات التي يتم فيها الإغلاق التلقائي لكل موظف .

 

وقد نجعل الأمر متروك لصلاحيات المدير الفرعي على سبيل المثال بأن يحدد انها مغادرة مفتوحة ، بحيث أتى الموظف E325 مثلاً وسجل حضور وتم ارساله الى مؤتمر لـ 3 أيام على سبيل المثال ، وبقيت كحضور مسجلة دون إنصراف ......

الأفكار كثيرة ومقرونة بالإحتمالات ومدى محدودية البرنامج بالطبع ..  

[ابوخليل]

هل تصدق ان ما طرحته انا هنا من تصور انه وليد اللحظة

أقرأ ما تكتب وافكر واكتب .. يمكن ان تلاحظ ذلك بالتعقيبات والتعديل

انت وجه مبارك .. 

سبق ان عملت قريبا من هذه الفكرة .. عملته لنادي من نوادي الحي .. ولكن الفرق وجود معيار  ( تاريخ اليوم )

ففي الحضور ليس هناك ضوابط في اي وقت يوقع

اما الانصراف فمربوط باليوم الحالي

[Foksh]

لكم جزيل الشكر على إطرائكم ولطفكم  .

عند التفكير بعمق وترتيب الأحداث التي قد تلي التخطيط وتنفيذها ، ستلاحظ أن الأفق في التنفيذ يتوسع قليلاً قليلاً لتجد أن الفكرة الصغيرة أصبحت مشروعاً شاملاً وكبيراً ..

الضابط كما أشرتم سيكون حقل التاريخ في أي حركة ، ما لم نتوسع بالإحتمالات والإمكانيات ..

في فكرة نظام الطابور والدور ، أضفت لوحة تحكم للمدير بإنهاء العملاء العالقين بتاريخ سابق أو اليوم . حيث جاءة الفكرة ببساطة أن النظام قد أصيب بخلل ، أو أنقطاع الكهرباء .... إلخ . لذا توجهت لمنح المدير حق الإنهاء للتذاكر القديمة التي سجلت بداية وقت خدمة ولم تسجل وقت نهاية . أو تم حجزها ولم يتم تسجيلها لأي موظف .... إلخ . رغم أن الفكرة بدأت لدي بقاعدة واحدة و 5 نماذج ( 3 موظفين وشاشة انتظار وشاشة حجز الدور ) ....

 

[ابوخليل]

تمام .. تخمرت الفكرة في رأسي 

سأجعل :

1- شرط وجود ضابط صغير  ( انتظار دقيقة او اكثر بين كل توقيعين ) من اجل تلافي الخطأ الغير مقصود

2-ولكن قد يكون هناك فكرة لتحديد حد زمني محدد للجلسة 

سأجعلهما في فورم تحكم .. بين يدي صاحب العمل 

جزاك الله خيرا .. وأحسن اليك

[Foksh]

وأياكم 😇

[jjafferr]

السلام عليكم

 

متابع الموضوع منذ البداية ، ولكن ليس في التفاصيل الدقيقة 🙂

هنا كتبت تجربتي في التعامل مع اجهزة البصمة ، وكان لك أخوي ابوخليل مشاركة كذلك:

 

.

خلاصة الفكرة: لا تُحمّل اكسس عبئ العمل كاملا ، فإجعل جهاز البصمة يقوم ببعض الاعمال الافتراضية التي تخصه ، واخذ الصافي ، ومنها استخدم قوة الاكسس.

 

وهذه مشاركة اخرى ، لسحب البيانات من جهاز البصمة ، والتي يحفظ البيانات بطريقة عمودية

 

[ابوخليل]

جزاك الله خير اخوي جعفر

نحن لم نناقش ادوات الحضور

وانما النقاش حول تأسيس العمل .. ربما المصطلحات توحي بغير ذلك

فانا مرة اذكر  توقيع وتسجيل والاخ فادي يذكر جلسة وبصمة

مشاركتي الأولى تعطي وصفا دقيقا للموضوع : حضور مفتوح يحسب بعدد ساعات التواجد

 

على كل حال انا انهيت العمل البارحة والطريقة ممتازة جدا ، حسب الفكرة الثانية كالتالي :

1- متغيران :

- واحد يحمل فترة بسيطة ( دقيقة مثلا) بين حركة التوقيع ( لتلافي تكرار التوقيع الغير مقصود)

- الثاني يحمل أقصى عدد ساعات العمل المحتملة ..( لإغلاق ثغرة بقاء حقل الانصراف فارغا )

هنا في الثاني .. لو لم يوقع الا بعد تجاوز الوقت المقرر .. فسيتم رصد الوقت المقرر للانصراف في النظام

[ابو جودي]

التحليل نظري لتصميم قاعدة البيانات

الفكرة:

• طبيعة العملية: مفتوحة، بلا قيود زمنية أو يومية
  الموظف يسجل بصمات حضور وانصراف متعددة (حتى 10 مرات مثلا أو أكثر يوميا) وقد تمتد البصمة عبر أيام (مثل حضور 10 مساء وانصراف 6 صباحا)
• التسلسل: البصمة الأولى حضور التالية انصراف ثم حضور، وهكذا دون حقل يحدد نوع البصمة
• الضابط: دقيقة واحدة على الأقل بين كل بصمتين لتجنب الأخطاء
• المخرجات: حصر ساعات العمل (الفرق بين الحضور والانصراف)
• تحدي إضافي: إمكانية نسيان بصمة انصراف مما يتطلب التعامل مع سجلات غير مكتملة

الخيارات لتصميم الجدول:

الخيار الأول: جدول بحقول  ( EmployeeID-  StartTime-  EndTime )

الوصف: كل سجل يحتوي على معرف الموظف - وقت الحضور - ووقت الانصراف
الإيجابيات:

• تصميم مباشر لتسجيل أزواج الحضور/الانصراف
• يسهل حساب ساعات العمل (  EndTime – StartTime )

السلبيات:

• غير مناسب لعملية مفتوحة حيث قد يسجل الموظف حضورا دون انصراف مؤقتا
• صعوبة التعامل مع بصمات مفقودة (مثل نسيان انصراف)
• أقل مرونة إذا كثرت التسجيلات أو تغيرت متطلبات النظام
• يتطلب معالجة معقدة لضمان التسلسل الصحيح

الخيار الثاني: جدول بحقول  ( EmployeeID -  RecordTime ) 

الوصف: كل بصمة تسجل كسجل مستقل بمعرف الموظف ووقت البصمة
نوع البصمة (حضور/انصراف) يحدد بناء على التسلسل (زوجي=حضور -  فردي=انصراف)

الإيجابيات:

• مرن جدا، يناسب العملية المفتوحة دون قيود زمنية
• يدعم تسجيل بصمات متعددة يوميا أو عبر أيام
• يتعامل مع نسيان بصمة انصراف بسهولة عبر الاستعلامات
• تطبيق ضابط الدقيقة بسيط عبر قيود أو برمجة

السلبيات:

• يتطلب استعلامات أكثر تعقيدا لربط الحضور بالانصراف وحساب ساعات العمل
• حجم الجدول قد يزداد بسبب تسجيل كل بصمة على حدة

التوصية 

الخيار الثاني هو الأنسب للأسباب التالية:

• المرونة: يدعم طبيعة العملية المفتوحة وتعدد البصمات دون قيود
• التعامل مع الأخطاء: يسمح بتحديد ومعالجة البصمات المفقودة (مثل نسيان انصراف) عبر استعلامات
• البساطة: لا حاجة لحقل نوع التسجيل لأن التسلسل يحدد النوع تلقائيا
• حصر ساعات العمل: يمكن تحقيقه باستعلامات تربط البصمات المتتالية

[ابوخليل]

18 دقائق مضت, ابو جودي said:

التوصية 

الخيار الثاني هو الأنسب للأسباب التالية:

• المرونة: يدعم طبيعة العملية المفتوحة وتعدد البصمات دون قيود
• التعامل مع الأخطاء: يسمح بتحديد ومعالجة البصمات المفقودة (مثل نسيان انصراف) عبر استعلامات
• البساطة: لا حاجة لحقل نوع التسجيل لأن التسلسل يحدد النوع تلقائيا
• حصر ساعات العمل: يمكن تحقيقه باستعلامات تربط البصمات المتتالية

☹️ 😞

سبق السيف العذل

عملت البارحة على الخيار الأول .. والآن في مرحلة التقارير

25 دقائق مضت, ابو جودي said:

السلبيات:

• غير مناسب لعملية مفتوحة حيث قد يسجل الموظف حضورا دون انصراف مؤقتا
• صعوبة التعامل مع بصمات مفقودة (مثل نسيان انصراف)
• أقل مرونة إذا كثرت التسجيلات أو تغيرت متطلبات النظام
• يتطلب معالجة معقدة لضمان التسلسل الصحيح

 

بعد اعداد وتصميم الفكرة بصورة محكمة .. هذه السلبيات لا وجود لها

وسوف اطرح هنا ان شاء الله مثالا بعد انتهائي منه 

وشكرا باشمهندس .. انت متوافق مع الاستاذ فادي

المثل يقول : لا يمدح السوق الا من ربح فيه

اقصد ان التصور لوحده لا يكفي بل يجب مباشرة تنفيذ الفكرتين .. حينها تتكشف الأمور 

 

[ابو جودي]

تحليل السلبيات وإمكانية التغلب عليها:

1. غير مناسب لعملية مفتوحة حيث قد يسجل الموظف حضورا دون انصراف مؤقتا:
   • السلبية: في جدول بحقول StartTime  و  EndTime  
     إذا سجل الموظف حضورا يدخل StartTime  ولم يسجل انصرافًا بعد، يبقى حقل EndTime فارغ مما يعقد التعامل مع السجلات غير المكتملة أثناء الحسابات
   • وردا على: يمكن معالجة هذا بتصميم محكم:
     • السماح بحقل EndTime بقيمة NULL مؤقتا مثلا مع معالجة السجلات غير المكتملة في الاستعلامات
       ( مثل استبعاد السجلات التي EndTime فيها NULL عند حساب ساعات العمل )
        
     • إضافة حقل حالة (Status) مثل "مفتوح" أو "مكتمل" لتتبع السجلات غير المكتملة
   • التقييم:
     ممكن التغلب عليها بإضافة قواعد ومعالجات إضافية فعلا ولكن هذا يزيد من تعقيد النظام مقارنةً بالخيار الثاني (سجل واحد لكل بصمة) حيث لا يحتاج إلى تتبع الحالة أو معالجة القيم الفارغة
      
2. صعوبة التعامل مع بصمات مفقودة (مثل نسيان انصراف):

السلبية: إذا نسي الموظف تسجيل انصراف يبقى EndTime  فارغ مما يؤثر على دقة حساب ساعات العمل ويتطلب تدخلا يدويا أو افتراضات (مثل تعيين وقت انصراف افتراضي)

• تصميم تقرير يحدد السجلات التي تحتوي على StartTime بدون EndTime لتسهيل التصحيح اليدوي
•  إضافة آلية تلقائية( مثل تعيين EndTime افتراضي بعد مدة معينة مثل 8 ساعات مع تنبيه المستخدم )

التقييم:
 ممكن لكن يتطلب برمجة إضافية أو تدخل يدوي
في المقابل:
 الخيار الثاني يتعامل مع البصمات المفقودة بشكل أسهل عبر الاستعلامات التي تحدد الحضور بدون انصراف بناء على التسلسل
 

3. أقل مرونة إذا كثرت التسجيلات أو تغيرت متطلبات النظام:

السلبية: هذا التصميم يفترض دائما أزواج حضور/انصراف إذا تغيرت المتطلبات
(مثل إضافة نوع تسجيل جديد مثل "استراحة" أو دعم تسجيلات غير متتالية) يصبح التعديل معقد

• تصميم الجدول بحيث يدعم إضافة حقول جديدة أو أنواع تسجيلات إضافية (مثل إضافة حقل RecordType )
• استخدام نموذج Access للتحكم في إدخال البيانات مما يسهل تعديل السلوك دون تغيير هيكل الجدول

التقييم: ممكن جزئيا لكن إضافة أنواع تسجيلات جديدة قد تتطلب إعادة هيكلة الجدول أو الاستعلامات
ولذلك يبقى الخيار الثاني أكثر مرونة لأنه يعتمد على سجلات مستقلة يمكن تخصيصها بسهولة

4. يتطلب معالجة معقدة لضمان التسلسل الصحيح:
   
   السلبية: التأكد من أن كل StartTime يتبعه EndTime صحيح يتطلب قواعد تحقق أو برمجة لمنع إدخال بصمات غير متسلسلة (مثل تسجيل انصراف قبل حضور)
   • استخدام نموذج Access يتحقق من آخر سجل قبل إدخال بصمة جديدة
     (مثل كود VBA للتحقق من وجود StartTime بدون EndTime )
   • إضافة قيد تحقق في الجدول لضمان أن EndTime يأتي بعد StartTime
   • التقييم: ممكن لكن يتطلب برمجة إضافية أو قيود معقدة
     الخيار الثاني يبسط التسلسل لأن كل بصمة مستقلة ويتم تحديد الحضور/الانصراف بناء على ترتيب الوقت

الخلاصة:

• كلام حضرتك صحيح: بتصميم محكم قد تتخطى هذه السلبية ولكن سوف يكون هناك ثمن
  مثل إضافة حقول حالة تقارير للسجلات غير المكتملة نماذج مع كود VBA وقيود تحقق و هذا يتطلب جهد إضافي في التصميم والبرمجة مما يزيد من تعقيد النظام وبالأخص كما أشرت عند محاولة إضافة أنواع تسجيلات جديدة في المستقبل لأي سبب مثل: "استراحة" أو "مأمورية عمل" أو دعم تسجيلات غير متتالية قد تتطلب إعادة هيكلة الجدول أو الاستعلامات
   
• لماذا الخيار الثاني لا يزال أفضل من وجهة نظرى المتواضعة ؟:
  • البساطة: يعتمد على سجلات مستقلة مما يقلل الحاجة إلى معالجات إضافية للتسلسل أو السجلات غير المكتملة
  • المرونة: يدعم التغييرات المستقبلية بسهولة (مثل إضافة أنواع تسجيلات جديدة)
  • التعامل مع البصمات المفقودة: يحدد الحضور بدون انصراف باستعلامات بسيطة دون الحاجة إلى حقول إضافية

[ابو جودي]

تحليلاتى السابقة نابعه عن تجارب عملية واحتكاك مباشر من بدء انشاء النظام الى التعامل به من خلال المستخدم النهائى الى التعديلات التى فرضت من المؤسسة مستقبلا 

ومن أجل ذلك تبدأ تحليلاتى دائما بـ 
التفكير فى العقبات - التفكير فى التحديثات التى قد تطرأ - التفكير بقدر الإمكان فى المشاكل 
وبناء علي ما سبق : يبدأ وضع التصور للتحليل المبدئى للنظام فأنا لا أبدأ بتحليل النظام أولا بناء على المعطيات الحالية فقط

فالبدء بالمعطيات الحالية حقا سوف يعطيك تحليلا دقيقا للنظام ولكن لهذه المعطيات الحالية والتى ان طرأ عليها أى تغيير مستقبلا ولم يتم أخذه فى الحسبان بقدر الإمكان قد يجبرك على إعادة هيكلة النظام أحيانا من جديد

يعنى مثل القاعدة الفقهيه : سد الزرائع مقدم على جلب المنافع

انا دائما افكر فى الزرائع والثغرات والعثرات والتطويرات المستقبليه التى قد تخطر على بالى لانه قد تعيقنى مستقبلا وتضرنى
اما محاولة إضفاء المرونة او المنافع والاضافات او بناء الاساس الذى يقبل الاضافات حتى لو لم يفيدنى حاليا لن يضرنى مستقبلا 

من أجل ذلك أحاول جاهدا حتى وإن أتعبنى ذلك فى الوقت الحالى وخاصة عند وضع الأساس 
اضع فى المقام الأول 
سد الثغرات
التفكير فى العقبات
التفكير فى التغيرات والمعطيات المستقبليه او المخرجات التى قد يُطلب الحصول عليها من النظام والتى قد تطرأ وتتطلب إضافتها فى المستقبل إعادة للهيكلة

لذلك اهتم دائما وقبل أى شئ بأكبر قدر ممكن من المرونه بوضع التصورات والخطط المستقبلية وفق المعطيات الحالية والمخرجات مع تصور أى معطيات أو مخرجات فى المستقبل تتعلق بالنظام ليكون العمل فى المستقبل
قابلا بقدر الامكان للتطوير بدون إعادة هيكلة ثم الجودة والكفائة فى الاداء والكفائه و الدقة فى النتائج  ..  هذه فكرى وهذه عقيدتى فى تصور وتحليل النظم عند وضع الخطة المبدئية قبل الشروع فى العمل

أعرف فى البدايه هو مجهد جدا جدا جدا 
ولكن فى النهاية ثماره عظيمه