محمد طاهر عرفه قام بنشر يوليو 4, 2003 قام بنشر يوليو 4, 2003 مراحل العمل فى البرنامج : لعمل لبرنامج بأسلوب علمي هناك ثلاث مراحل متتالية : أولا ً : تحليل النظام : ثانيا : تصميم النظام : ثالثا : التنفيذ ( أو البرمجة ) الكثير من المبرمجين يتعاملون مع أول مرحلتين ، علي أنهما تحصيل حاصل ، و أنه يمكن تجاوزهما بناء علي الفهلوة أو الخبرة – تبعا لنظرية : العلم فى الراس مش فى الكراس. :lol: و لا أخفيكم أني كثيرا ما أفعل هذا ، و لكن لاتباع الاسلوب العلمي فى اعداد البرنامج فوائد جمة، أهمها هو التوثيق و سهولة استرجاع معلومات التصميم سواء من المبرمج نفسه أو من من يكمل العمل بعده فى نفس البرنامج و هذا يقودني الي كلمة طالما تحدثت عنها مع إخوان لكم فى مواقع مماثلة ، و لكن دائما كانت تلقي القبول و ليس لها حظ كبير من التنفيذ ، الا و هي " التوثيـــــــــــــــق " و هذه الكلمة كما لها علاقة بالاكسس و البرمجة ، لها علاقة كبيرة بحياتنا كلها ، لذا أستميحكم عذرا أن أعرض لها علي عجالة قبل أن أكمل التوثيق و تناقل و حفظ الخبرات الفرق الاساسي و الكبير (( من وجهة نظري المتواضعة )) بيننا و بين ما يسمونه دول العالم الاول من ناحية الادارة ، هو النظام الاداري الموثق المتبع فى كل شيء فى العمل ، و عليه فيتم تناقل الخبرات بصورة كبيرة و دائما هناك إكمال للمسيرة و البداية من حيث إتنهي الأخرون و ليس من الصفر فالمؤسسات صغرت أم كبرت ، لديها نظام إداري محكم و مكتوب ، و الجميع يلتزم به و يعرف حقوقه وواجباته ، و المشاكل يتم توثيقها ليستفيد بها الغير . و لكي تتضح الصورة لما أقصد سأضرب لكم مثلين تعرضت لهما شخصيا فى العمل مع الأجانب ، و أثرا في كثيرا. الأول كنت أعمل فى إحدي الدول العربية ، و كنت أتبع أحد الأجانب إداريا. و طلب مني القيام بعمل ما و اطلاعه علي ال Procedure أو وثيقة الاجراءات للعمل الذي سأقوم به قبل البدء. فاستغربته ، و ظننت أني بانجاز العمل مباشرة سأبهره ، و فعلا أعددته بسرعة و عرضته عليه ، فاستغرب جدا ، و قال لي " لا يمكن أن يقوم إنجليزي يعمل فى شركة كبيرة بمثل هذا العمل قبل أن يكون هناك وثيقة مكتوبة لأسلوب العمل " و أصر و أراني وثيقة مماثلة لما يقصد ، و بعد قرائتها و اعداد مثيلة لها علي مضض ، فهمت المغزي من وراء ذلك. هذه الوثيقة تم فيها تحديد المعايير المختلفة لأسلوب العمل ، و تحديد الفرضيات التي يم بناء الحسابات عليها ، باختصار وصف لكل ما كنت سأضطر لشرحه لأي شخص يريد فهم تفاصيل العمل الذي قمت به ، و مع الوقت وفرت علي هذه الوثيقة الكثير من الكلام عند مراجعة هذا العمل مع أشخاص مختلفين ، و عند تسليم هذا العمل لشخص آخر ، و أيضا حينما أعيد إسناد نفس العمل لي فى وقت لاحق . أيضا أثناء مناقشة مشكلة فنية ، تصورت أن المرجع الوحيد للمناقشة هو الخبرة و المنطق ، و بعد فترة من النقاش ، أخرج الأجنبي ملفات و رجع اليها ، ثم قال عندما اتبع هذا الحل فى بلد كذا فى مشروع كذا .. كانت العيوب كذا .. و الحل الآخر .. ميزاته كذا .. و ... ، يعني وجدت خبرة شركته فى جميع أنحاء العالم منذ عشرات السنين موثقة و مكتوبة و متاحة له و لباقي مسئولي الشركة . و هنا أدركت أهمية التوثيق و تناقل الخبرات ، و عرفت أحد أهم أسباب ما قد يسمي بالتقدم الاداري و التخلف الاداري ، الا و هو التوثيق نعود لموضوعنا :) و عليه فان توثيق البرنامج من الأهمية بمكان لك و لغيرك ، فنصيحتي لكم و لنفسي الا نتجاوز المرحلتين الأوليين ، و الا نمر عليهما مرور الكرام ما يلي هو تصورات شخصية ، من الخبرة و بعض الكتب ، و لا يجب اعتباره مرجع علمي ، و انما هي تصوراتي و خبرتي أنقلها اليكم للنقاش حولها : أولاً تحليل النظام : تحليل النظام هو فهمنا للنظام المطلوب انشاؤه و لكي نصل الي هذا الفهم : 1. نفهم قواعد نظام العمل 2. مواصفات احتياجات و متطلبات العميل 3. تخطيط مبدئ لشكل واجهة الاستخدام ( من ناحية طلبات العميل ) أو بمعني آخر هي مرحلة تجميع للبيانات الخاصة بالنظام المطلوب عمل برنامج له و يمكن تصنيف المعلومات الي : 1. المدخلات 2. المخرجات 3. النقاط الواجب مراعاتها 4. وصف عام لعمل البرنامج و مجاله أي ماذا سيغطي و ماذا لن يتطرق اليه هذا البرنامج _ و ما هي النقاط التي تؤثر فيه 5. رسم Flow Chart يمثل آلية نظام العمل • و في نهاية هذه المرحلة يتم اعداد مستند يسمي مستند لتحليل النظام . ثانيا تصميم النظام : بناء علي مستند تحليل النظام تبدأ هذه المرحلة : ملاحظة : أن هذا الكلام كله بعيدا عن التصميم و الجداول و الكائنات و الأكسس ككل ، و انما مجرد وصف و تحليل منطقي للنظام ، و لا يرد ذكر الجداول الا في المرجلة الاخيرة و هي بدء تنفيذ البرنامج ( تصميم الجداول) باختصار ما يتم فى هذه المرحلة هو تصميم البرنامج علي الورق ، أي تصور للبرنامج و امكانياته و هيكله و الاهدافه و قواعده و الحركة داخله ، و العمل اليومي عليه ، و تفاصيل شاشاته و استعلاماته و تقاريره أو بمعني أبسط ، توثيق ما يتخيله المبرمج عن البرنامج قبل أن يبدأ التنفيذ . و فى هذا فائدة عظيمة لأن التوثيق مفيد سواء فى حال الرغبة فى التعديل بعد فترة أو حينما يكمل مبرمج آخر العمل في المشروع كما ذكرنا سابقا. أحيانا أحب أن أسمي هذه المرحلة ( شخبطة البرنامج ) ، فانما هي تنفيذ البرنامج و توثيق الفكر المتبع فيه و لكن علي الورق. أو أيضا بمعني آخر ترجمة و توثيق للمعطيات التي حصل عليها المبرمج ( علي الورق ) و توجد بعض الاساليب العلمية فى التصميم مثل اسلوب علاقات الكائنات Entity relationship diagram ERD و الذي يغني عن الخبرة فى ترجمة التحليل و التصميم الي تنفيذ ( جداول ) ، و سنعرض له فى موضوع منفصل و أحد التصورات عن مرحلة التصميم هي كالتالي 1- الوصف العام للنظام a. وصف ملخص للنظام b. أهداف النظام نقاط محددة توضح فوائد النظام و الخدمات الني يقدمها c. هيكله هيكل تنظيمي Flow Shart يوضح الاجزاء الرئيسية للبرنامج ( من حيث التقسيم و ليس النماذج) أي بمعني أكثر وضوحا الاعمال الرئيسية التي يغطيها البرنامج و التفاصيل التي تندرج تحت كل منها d. القواعد العامة لاستخدامه وصف عام و ليس تفصيلي لشاشات العرض وصف عام لشاشات الادخال اللانتقال بين الحقول و الاختصارات المستخدمة قواعد عامة لكتابة المدخلات قواعد عامة فى النماذج قواعد عامة فى الطباعة و التقارير قواعد تسمية الشاشات قواعد تسمية التقارير أنواع الصلاحيات المختلفة فى البرنامج 2- الحركة داخل النظام فى هذا الجزء ، سيكون هناك شكل للشاشات و التقارير ( كروكي ) بدون تنسيق مصحوب بوصف للبيانات الموجودة فى كل شاشة و بيانات الحركة منها الي الشاشات المختلفة ، و بيان الصلاحيات النختلفة للتعامل مع كل شاشة و كل جزء منها ان وجد . 3- العمل اليومي و الدوري علي البرنامج وصف للعمل اليومي علي البرنامح و ما يقوم به كل من المستخدمين وصف للعمل الدوري علي البرنامح ( المهام التي يقوم بها المستخدم فى نهاية كل فترة أو كل مرحلة من مراحل الاستخدام ) و ما يقوم به كل من المستخدمين ( مثل الجرد مثلا ) 4- ادارة النظام وصف للعمليات الخاصة بالادارة و النقاط الواجب مراعاتها فيها مثل النسخ الاحتياطي ، و التوجيه علي الشبكة ، ... و بعد انتهاء هذا الجزء ، يبدأ الجزء الثاني من المرحلة الثانية و هو ال ERD كما سبق او تخطيها و القفز مباشرة الي تصميم– و هذا الحل سيعتمد علي الخبرة أكثر من الترتيب العلمي للعمل ، و فى حالة الدخول الي التصميم مباشرة يجب الاهتمام بتوثيقه و شرحه شاملا التصميم و العلاقات و كيفية اختيارها ثالثا التنفيذ و هو الذي يبدأ بتحديد الهيكل العام للجداول و العلاقات بعض الملاحظات الخاصة بالتسميات • يجب كون التسميات للحقول و الكائنات بالانجليزية ، و يفضا استخدام نسخة الأكسس ذات واجهة التطبيق اللإنجليزية – و هذا ليس حبا فى الانجليزية و لكن لأن العربية لها مشاكل مع كتابة أكود البيزيك . • يجب وجود نظان ثابت للتسميات بمعني أنه علي سبيل المثال فى البداية كنت أفضل البدايات المختصرة للتسميات مثل : o كل النماذج تبدأ بحرف F – فيكون نموذج الموظفين اسمه FEMP أو F_EMP o كل التقارير تبدأ ب R و الاستعلامات تبدأ ب Q و بعد عدة مناقشات لنظام تسميات طرحه الأخ أبو هاجر استنادا الي موقع ميكروسوفت ، وصل المتناقشين الي قناعة بأن هذا النظام هو الأفضل الا و هو الموجود هنا http://www.officena.net/Tips/Naming.htm هناك بعد الاقتراحات الاضافية : للتسميات ، و هي ليس لها ممرجع و لكن تفضيلات شخصية : o في حالة كون الحقل يعبر عن كود فيكون فى نهايته C مثلا كود العامل EMP_C أو EMP-C أو EMPC مثلا o في حالة كون الحقل يعبر عن اسم فيكون فى نهايته N مثلا كود العامل EMP_N أو EMP-N أو EMPN مثلا o في حالة كون الحقل يعبر عن وصف فيكون فى نهايته D أو DES مثلا كود الحالة STATUS_D أو STATUS -D أو STATUS-DES مثلا موضوع الحوار حول هذه الحلقة من هنا و هو مفتوح للحوار من 5-7-03 حتي 11-7-03 بإذن الله 1
الردود الموصى بها
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.