30-04-2012, 09:22 PM
السلام عليكم
مقترح لمعيار تقدير تكلفة منظومات تطبيقات قواعد البيانات
أغلب التطبيقات التي يقوم باعدادها المطورين في بلادنا حاليا هي
تطبيقات الأعمال المرتكزة على قواعد البيانات. وبرغم مرور زمن على
صناعة البرمجيات واستخدام التطبيقات البرمجية في الجهات العامة
والخاصة لدينا، إلا أن هنالك دائما اضطراب وحيرة تواجه المطور
والزبون معا في كيفية الاتفاق على تسعيرة لتكلفة ترضي الطرفين،
وقبل ذلك أن تجعل من كلا الطرفين على قناعة مشتركة بأسس هذا
التسعير.
السائد الآن هو أن يطرح المطور تسعيرته بناء على معطيات يراها أو
بناء على ما هو سائد في السوق، وعلى الزبون أن يقرّر ما إذا كانت
هذه التسعيرة مناسبة له أم لا بناء على معطيات يراها هو أيضا وعلى
ما هو سائد في السوق.
إلا أن المعطيات التي يراها الطرفان متباينة وغامضة، فكل طرف يتصوّر
التسعيرة المناسبة بناء على حدس وتخمين وليس على أساس واضح
وملموس.
فالمطوّر وإن كان قد بنى تسعيرته على أسس محددة كتقديره للمدة
المتوقعة لإنجاز العمل، أو استنادا لخبرة سابقة في منظومات مشابهة،
فإنه لا يستطيع أن يقدّم للزبون ما يقنعه بهذا التقدير، بل غالبا لا يستطيع
أن يقنع نفسه بذلك.
أما الزبون، فبالتأكيد لا يستطيع أن يحدّد السعر المناسب، إلا إذا كان
ذو تجارب متكررة ومتشابهة، ولكن في الأغلب ليس لديه إلا ما هو
سائد في السوق، و ثقته بالمطور الذي أمامه، والأهم المنفعة التي
ستعود إليه إذا قام باقتناء هذا البرنامج بذاك السعر.
إننا نحتاج لمعيار يستطيع الطرفان المطوّر والزبون أن يتفقا عليه،
وأن يكون هذا المعيار مفهوما لدى الزبون وله معناه ودلالته في
المنظومة التي يريدها ويكون أساسا مقنعا له في تقدير قيمة العمل
المطلوب. بالمقابل بالنسبة للمطوّر يجب أن يكون هذا المعيار يعكس
بدرجة مقبولة حجم الجهد الذي سيبذله في سبيل إنجاز العمل.
منطلق المعيار الذي ساقترحه هو السوال التالي:
في منظومة قواعد بيانات؛ ما هو العنصر الذي إذا تغيرت كميته تغيرت
كمية الجهد المبذول على معظم نواحي المنظومة؟
الإجابة الأولى لدي كانت حقول قاعدة البيانات. فالملاحظ أن كل حقل
يتم اضافته لجدول في قاعدة البيانات يترتب عنه كمّ من الجهد البرمجي
يتوزّع على معظم نواحي المنظومة.
القائمة التالية تسرد بعضا من أنواع الجهد البرمجي الذي قد يرافق
إنشاء كل حقل:
- وضع الحقل بطريقة تضمن الاتساق العام لتصميم و معمارية التطبيق،
وربما إعادة هيكلتهما.
- إضافة مداخل الحقل في الصنفيات ذات العلاقة: الصنفيات الأساسية
والفرعية كصنفيات طبقات البيانات، والعرض.
- خانة على واجهة الاستخدام لاستقبال بياناتها من المستخدم.
- قائمة بمقترحات البيانات تقدّم للمستخدم للإختيار منها.
- تعليمات برمجية للتحقق من صلاحية بيانات الخانة.
- تعليمات برمجية للتحقق من عدم تكرار المعلومة المدخلة.
- تعليمات برمجية لمناولة ادخال بيانات الحقل داخل قاعدة البيانات.
- خانة أو أكثر لإستظهار بيانات الحقل.
- تعليمات برمجية لمناولة إدخال وتعديل وإستخراج بيانات الحقل في
قاعدة البيانات.
- تعليمات برمجية لتضمينها في شروط البحث أو الاستعلام.
- خانة أو أكثر ضمن تصميم صفحات التقارير.
- تعليمات برمجية عند إعداد التقارير بحسب أعداد هذه التقارير.
- تعليمات إضافية داخل قاعدة البيانات، كإجرائيات مخزنة أو مبدلات.
- تعليمات لتضمينها ضمن صلاحيات المستخدم للإضافة والعرض والتعديل
والإلغاء.
- شروحات في دليل الاستخدام أو ملف المساعـدة.
القائمة السابقة كما أسلفنا هي سرد لبعض أنواع جهود التصميم
والبرمجة التي تصاحب كل حقل، وتزيد وتتعمق هذه الجهود البرمجية بحسب
متطلبات المنظومة الوظيفية والفنية.
إن الافتراض بأن حجم الجهد البرمجي في منظومة يتناسب مع عدد الحقول
بها، قد لا يكون حقيقيا تماما ولكن بالتأكيد يعكس جانبا كبيرا من
الواقع، وهذا ما يشجع على تحسّس إمكانية اعتباره أساسا أو معيارا
لتقدير تكلفة بناء منظومة قواعد بيانات.
تطبيقا لهذه المقاربة بأبسط صورها، دعنا نقول أن تكلفة الحقل الواحد
مثلا 30 دينار. سيكون تقدير تكلفة منظومة بها 40 حقلا هو 1200 دينار.
طبعا الأمور ليس بمثل هذه البساطة، لذلك سنناقش بعض التفاصيل الأخرى.
الحقول الخاضعة للحسبة يجب أن تكون مفهومة لدى الزبون ولها دلالة
مباشرة لما ستقوم به المنظومة، مثل: إسم الفرد، العنوان، تاريخ الميلاد،
مكان الميلاد. لذلك سوف نستبعد الحقول التي ليس لها معنى لدى الزبون
مثل حقل الرقم المميز لكل سجل أو كائن، أو حقول الربط في الجداول
المساعـدة، وعلى هذا عوضا عن كلمة "حقل" سوف نستخدام كلمة "خانة"
التي يستطيع أن يستوعبها الزبون.
ولكن هل عدد الخانات وحده كاف لتقدير حجم العمل؟ التطبيقات البرمجية
تتباين في خصائصها ومتطلباتها الفنية، لهذا توجد عدة عوامل أو عناصر
أخرى يجب أن تؤخذ في الحسبان، مع شرط أن تكون هذه العوامل مفهومة
قدر الإمكان لدى الزبون. هذه العناصر يجب تبيانها وتحديدها و تحديد
نصيبها من القيمة التي يجب أن تضاف لقيمة الخانة الواحدة.
مثال على هذه العوامل:
هل قاعدة البيانات مكتبية أم بتقنية خادم/عميل؟ إذا كانت الأخيرة
يتم إضافة قيمة أخرى إلى القيمة الأصلية للخانة ولتكن 10 دينار
مثلا.
عدد التقارير المطلوب إنجازها، ويتم إضافة قيمة لكل تقرير ولنقل
نصف دينار.
هل يوجد دليل تشغيل للمنظومة، يضاف 10 دينار.
واستكمالا لمثالنا السابق، اذا افترضنا أن المنظومة ستكون بتقنية
خادم/عميل، بعشرة تقارير مع وجود دليل استخدام، فإن سعر الخانة
سيكون: 30 + 10 + (10 × 0.5) + 10 = 55 دينار.
وبالتالي تكون اجمالي تكلفة المنظومة ذات 40 خانة 2200 دينار.
(سأحاول في موضوع آخر سرد العناصر التي توثر في حجم بناء المنظومة)
ملاحظات عامة:
- الأسعار الواردة أعلاه هي لغرض توضيح الفكرة، ربما نلجأ إلى
استبدالها بنقاط، ثم يتم ترجمة هذه النقاط إلى عملة كل بلد حسب
أسعار العمل ومستوى المعيشة فيه.
- تحديد السعر أو عدد النقاط، يجب أن يخضع لدراسة مستفيضة يشارك
فيها المطورون المتمرسون في مثل هذه التطبيقات واستقراء للمنظومات
القائمة، حتى نصل إلى أرقام تعكس الواقع العملي قدر الإمكان.
- تقدير التكلفة أثناء أو بعد تنفيذ المنظومة: من المعلوم إن
إدخال أي تعديل أو إضافة على المنظومة بعد أن تكون قد قطت
شوطا في عملية التنفيذ؛ تعد من الأمور المربكة لمطوّري المنظومة،
وتستلزم الكثير من جهود التصميم والبرمجة التي قد تؤدّي إلى إعادة
التصميم أو البرمجة في كثير من نواحيها. لذلك من المنطقي أن يعاد
تقدير تكلفة الخانة بالزيادة على تكلفتها التي تم تقديرها قبل
بدء تنفيذ المنظومة.
- مشاركة الزبون: من المزايا التي يمكن أن نتحصل عليها عند
تطبيق هذا المعيار، هو دفع الزبون إلى وضعية يستطيع فيها أن
يقرر بنفسه ما يحتاجه في المنظومة من مزايا وظيفية وفنية، وبما
أنه يعلم تماما تكلفة كل قرار سيتخذه، فإن ذلك يجعله أكثر
حرصا وتعقلا عند تقرير نطاق عمل المنظومة. كذلك سيجنب المطور
مخاطر رغبات الزبون غير المحسوبة في التغيير والزيادة والتعديل
بعد انطلاق العمل في تنفيذ المنظومة.
- تقسيم أجزاء العمل وتحديدها بتفصيل أكثر يسهم في إزالة الغموض
لدى الزبون عن التطبيق المراد تطويره، ويزيد من ثقته بالمطور
في تقديره للتكلفة.
ماذا عن تقدير الوقت اللازم للتنفيذ؟
المعيار المقترح هو لتقدير تكلفة المنظومة، لكن هل هذا المعيار سيكون
صالحا لتقديرالوقت اللازم لتنفيذ المنظومة؟ هل لو حددنا أن الزمن
المقدر لتنفيذ خانة هو نصف يوم، فهل يصلح أن نقول أن المنظومة التي
تحوي 40 خاتات سيستغرق تنفيذها 20 يوم؟
هذا أمر يحتاج لمزيد من البحث و الدراسة.
الآن؛ لا أعلم مدى نجاعة هذا الاقتراح أو مدى تطبيقه عمليا،
وانتظر أراء كم وملاحظاتكم.
وآسف على الإطالة.
مقترح لمعيار تقدير تكلفة منظومات تطبيقات قواعد البيانات
أغلب التطبيقات التي يقوم باعدادها المطورين في بلادنا حاليا هي
تطبيقات الأعمال المرتكزة على قواعد البيانات. وبرغم مرور زمن على
صناعة البرمجيات واستخدام التطبيقات البرمجية في الجهات العامة
والخاصة لدينا، إلا أن هنالك دائما اضطراب وحيرة تواجه المطور
والزبون معا في كيفية الاتفاق على تسعيرة لتكلفة ترضي الطرفين،
وقبل ذلك أن تجعل من كلا الطرفين على قناعة مشتركة بأسس هذا
التسعير.
السائد الآن هو أن يطرح المطور تسعيرته بناء على معطيات يراها أو
بناء على ما هو سائد في السوق، وعلى الزبون أن يقرّر ما إذا كانت
هذه التسعيرة مناسبة له أم لا بناء على معطيات يراها هو أيضا وعلى
ما هو سائد في السوق.
إلا أن المعطيات التي يراها الطرفان متباينة وغامضة، فكل طرف يتصوّر
التسعيرة المناسبة بناء على حدس وتخمين وليس على أساس واضح
وملموس.
فالمطوّر وإن كان قد بنى تسعيرته على أسس محددة كتقديره للمدة
المتوقعة لإنجاز العمل، أو استنادا لخبرة سابقة في منظومات مشابهة،
فإنه لا يستطيع أن يقدّم للزبون ما يقنعه بهذا التقدير، بل غالبا لا يستطيع
أن يقنع نفسه بذلك.
أما الزبون، فبالتأكيد لا يستطيع أن يحدّد السعر المناسب، إلا إذا كان
ذو تجارب متكررة ومتشابهة، ولكن في الأغلب ليس لديه إلا ما هو
سائد في السوق، و ثقته بالمطور الذي أمامه، والأهم المنفعة التي
ستعود إليه إذا قام باقتناء هذا البرنامج بذاك السعر.
إننا نحتاج لمعيار يستطيع الطرفان المطوّر والزبون أن يتفقا عليه،
وأن يكون هذا المعيار مفهوما لدى الزبون وله معناه ودلالته في
المنظومة التي يريدها ويكون أساسا مقنعا له في تقدير قيمة العمل
المطلوب. بالمقابل بالنسبة للمطوّر يجب أن يكون هذا المعيار يعكس
بدرجة مقبولة حجم الجهد الذي سيبذله في سبيل إنجاز العمل.
منطلق المعيار الذي ساقترحه هو السوال التالي:
في منظومة قواعد بيانات؛ ما هو العنصر الذي إذا تغيرت كميته تغيرت
كمية الجهد المبذول على معظم نواحي المنظومة؟
الإجابة الأولى لدي كانت حقول قاعدة البيانات. فالملاحظ أن كل حقل
يتم اضافته لجدول في قاعدة البيانات يترتب عنه كمّ من الجهد البرمجي
يتوزّع على معظم نواحي المنظومة.
القائمة التالية تسرد بعضا من أنواع الجهد البرمجي الذي قد يرافق
إنشاء كل حقل:
- وضع الحقل بطريقة تضمن الاتساق العام لتصميم و معمارية التطبيق،
وربما إعادة هيكلتهما.
- إضافة مداخل الحقل في الصنفيات ذات العلاقة: الصنفيات الأساسية
والفرعية كصنفيات طبقات البيانات، والعرض.
- خانة على واجهة الاستخدام لاستقبال بياناتها من المستخدم.
- قائمة بمقترحات البيانات تقدّم للمستخدم للإختيار منها.
- تعليمات برمجية للتحقق من صلاحية بيانات الخانة.
- تعليمات برمجية للتحقق من عدم تكرار المعلومة المدخلة.
- تعليمات برمجية لمناولة ادخال بيانات الحقل داخل قاعدة البيانات.
- خانة أو أكثر لإستظهار بيانات الحقل.
- تعليمات برمجية لمناولة إدخال وتعديل وإستخراج بيانات الحقل في
قاعدة البيانات.
- تعليمات برمجية لتضمينها في شروط البحث أو الاستعلام.
- خانة أو أكثر ضمن تصميم صفحات التقارير.
- تعليمات برمجية عند إعداد التقارير بحسب أعداد هذه التقارير.
- تعليمات إضافية داخل قاعدة البيانات، كإجرائيات مخزنة أو مبدلات.
- تعليمات لتضمينها ضمن صلاحيات المستخدم للإضافة والعرض والتعديل
والإلغاء.
- شروحات في دليل الاستخدام أو ملف المساعـدة.
القائمة السابقة كما أسلفنا هي سرد لبعض أنواع جهود التصميم
والبرمجة التي تصاحب كل حقل، وتزيد وتتعمق هذه الجهود البرمجية بحسب
متطلبات المنظومة الوظيفية والفنية.
إن الافتراض بأن حجم الجهد البرمجي في منظومة يتناسب مع عدد الحقول
بها، قد لا يكون حقيقيا تماما ولكن بالتأكيد يعكس جانبا كبيرا من
الواقع، وهذا ما يشجع على تحسّس إمكانية اعتباره أساسا أو معيارا
لتقدير تكلفة بناء منظومة قواعد بيانات.
تطبيقا لهذه المقاربة بأبسط صورها، دعنا نقول أن تكلفة الحقل الواحد
مثلا 30 دينار. سيكون تقدير تكلفة منظومة بها 40 حقلا هو 1200 دينار.
طبعا الأمور ليس بمثل هذه البساطة، لذلك سنناقش بعض التفاصيل الأخرى.
الحقول الخاضعة للحسبة يجب أن تكون مفهومة لدى الزبون ولها دلالة
مباشرة لما ستقوم به المنظومة، مثل: إسم الفرد، العنوان، تاريخ الميلاد،
مكان الميلاد. لذلك سوف نستبعد الحقول التي ليس لها معنى لدى الزبون
مثل حقل الرقم المميز لكل سجل أو كائن، أو حقول الربط في الجداول
المساعـدة، وعلى هذا عوضا عن كلمة "حقل" سوف نستخدام كلمة "خانة"
التي يستطيع أن يستوعبها الزبون.
ولكن هل عدد الخانات وحده كاف لتقدير حجم العمل؟ التطبيقات البرمجية
تتباين في خصائصها ومتطلباتها الفنية، لهذا توجد عدة عوامل أو عناصر
أخرى يجب أن تؤخذ في الحسبان، مع شرط أن تكون هذه العوامل مفهومة
قدر الإمكان لدى الزبون. هذه العناصر يجب تبيانها وتحديدها و تحديد
نصيبها من القيمة التي يجب أن تضاف لقيمة الخانة الواحدة.
مثال على هذه العوامل:
هل قاعدة البيانات مكتبية أم بتقنية خادم/عميل؟ إذا كانت الأخيرة
يتم إضافة قيمة أخرى إلى القيمة الأصلية للخانة ولتكن 10 دينار
مثلا.
عدد التقارير المطلوب إنجازها، ويتم إضافة قيمة لكل تقرير ولنقل
نصف دينار.
هل يوجد دليل تشغيل للمنظومة، يضاف 10 دينار.
واستكمالا لمثالنا السابق، اذا افترضنا أن المنظومة ستكون بتقنية
خادم/عميل، بعشرة تقارير مع وجود دليل استخدام، فإن سعر الخانة
سيكون: 30 + 10 + (10 × 0.5) + 10 = 55 دينار.
وبالتالي تكون اجمالي تكلفة المنظومة ذات 40 خانة 2200 دينار.
(سأحاول في موضوع آخر سرد العناصر التي توثر في حجم بناء المنظومة)
ملاحظات عامة:
- الأسعار الواردة أعلاه هي لغرض توضيح الفكرة، ربما نلجأ إلى
استبدالها بنقاط، ثم يتم ترجمة هذه النقاط إلى عملة كل بلد حسب
أسعار العمل ومستوى المعيشة فيه.
- تحديد السعر أو عدد النقاط، يجب أن يخضع لدراسة مستفيضة يشارك
فيها المطورون المتمرسون في مثل هذه التطبيقات واستقراء للمنظومات
القائمة، حتى نصل إلى أرقام تعكس الواقع العملي قدر الإمكان.
- تقدير التكلفة أثناء أو بعد تنفيذ المنظومة: من المعلوم إن
إدخال أي تعديل أو إضافة على المنظومة بعد أن تكون قد قطت
شوطا في عملية التنفيذ؛ تعد من الأمور المربكة لمطوّري المنظومة،
وتستلزم الكثير من جهود التصميم والبرمجة التي قد تؤدّي إلى إعادة
التصميم أو البرمجة في كثير من نواحيها. لذلك من المنطقي أن يعاد
تقدير تكلفة الخانة بالزيادة على تكلفتها التي تم تقديرها قبل
بدء تنفيذ المنظومة.
- مشاركة الزبون: من المزايا التي يمكن أن نتحصل عليها عند
تطبيق هذا المعيار، هو دفع الزبون إلى وضعية يستطيع فيها أن
يقرر بنفسه ما يحتاجه في المنظومة من مزايا وظيفية وفنية، وبما
أنه يعلم تماما تكلفة كل قرار سيتخذه، فإن ذلك يجعله أكثر
حرصا وتعقلا عند تقرير نطاق عمل المنظومة. كذلك سيجنب المطور
مخاطر رغبات الزبون غير المحسوبة في التغيير والزيادة والتعديل
بعد انطلاق العمل في تنفيذ المنظومة.
- تقسيم أجزاء العمل وتحديدها بتفصيل أكثر يسهم في إزالة الغموض
لدى الزبون عن التطبيق المراد تطويره، ويزيد من ثقته بالمطور
في تقديره للتكلفة.
ماذا عن تقدير الوقت اللازم للتنفيذ؟
المعيار المقترح هو لتقدير تكلفة المنظومة، لكن هل هذا المعيار سيكون
صالحا لتقديرالوقت اللازم لتنفيذ المنظومة؟ هل لو حددنا أن الزمن
المقدر لتنفيذ خانة هو نصف يوم، فهل يصلح أن نقول أن المنظومة التي
تحوي 40 خاتات سيستغرق تنفيذها 20 يوم؟
هذا أمر يحتاج لمزيد من البحث و الدراسة.
الآن؛ لا أعلم مدى نجاعة هذا الاقتراح أو مدى تطبيقه عمليا،
وانتظر أراء كم وملاحظاتكم.
وآسف على الإطالة.
