تقدير حجم البرمجيات

تقدير حجم البرمجيات^(*)

البرمجيات⁽¹⁾، على خلاف النفط والفولاذ والورق، هي سلعة غير مادية.

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

<C. جونز>

 

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

 

وعلى الرغم من أهميتها، فقد بقيت البرمجيات كمّا غير ملموس ومراوغًا عند قياسه. ونتساءل كيف ينبغي تحديد حجم البرمجيات؟.

 

وهذا السؤال ليس تمرينًا أكاديميًّا فحسب. ففي غياب معيار جيد للبرمجيات تجد الصناعة صعوبة في تحسين جودة التطبيقات الحاسوبية وزيادة فاعلية تطويرها. وبالفعل فإن لدى معظم الشركاتِ والمؤسساتِ الحكومية فكرة مبهمة عن مستوى برمجياتها وإنتاجية مُبَرمجيها. وبالتالي فإن التكهن بالاستثمارات المالية والزمن اللازمين لإنشاء البرامج مهمة صعبة للغاية حتى أصبح تجاوز الموازنة والتأخير القاعدة لا الاستثناء.

 

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

 

بالطبع هناك طريقة لقياس حجم البرمجيات، وهي أن تُعد بكل بساطة جميع البايتات bytes التي يشغلها برنامج معين على قرص التخزين للحاسوب. وهناك أسلوب آخر يقضي بأن تُعدَّ أسطر «الكود» البرمجي، المكوّن من اللائحة الطويلة للتعليمات التي يحتاج إليها كل تطبيق حاسوبي. ولكن مثل هذه القياسات لا تعكس دائمًا مدى القدرة الحقيقية للبرمجيات. إذ نجد أحيانًا أن برنامجًا مكونًا من ثلاثة ملايين سطر أغنى بالوظائف والإمكانات من تطبيق يحوي خمسة ملايين سطر.

 

وثمَّة توجه أفضل يركّز على تقييم العمليات التي يقوم بها برنامج معين. وإحدى الطرق المنهجية للقيام بذلك تعتمد على عدّ «نقاط وظيفية» functionpoints  تشكل مؤشرات كميّة لما يستطيع البرنامج القيام به. وقد مهّد علماء الحاسوب لهذا النموذج المنهجي منذ أكثر من عقدين من الزمن. وقريبًا قد ينتج من هذه الجهود معايير دولية. ومع ذلك ليس مؤكدًا إطلاقًا أنه سينبثق من فكرة النقاط الوظيفية نظام عمومي لقياس البرمجيات.

 

ما البرمجيات على وجه التحديد؟

ليست الحواسيب الرقمية بحد ذاتها سوى حاويات للبرمجيات التي تُشغّلُها. ويقوم قارئ الأقراص المدمجة بدور مماثل. إذا كان القرص في القارئ يحوي سيمفونية لموتسارت mozart  يسمع المستمع موسيقى كلاسيكية، وإذا كان يحوي موسيقى لـ <B. هوليدي> يسمع الجاز. كذلك باستخدام برمجيات مختلفة يمكن للحاسوب أن يُستخدم لمعالجة الكلمات ولمنابلة الصحائف الجدولية spreadsheets  أو لقراءة وثائق من الشبكة العنكبوتية العالمية (الويب)World Wide Web.

 

تتألف البرمجيات من سلسلة مكونة من آلاف أو أحيانًا ملايين من التعليمات الفردية التي تأمر الحاسوب بأداء حركات مختلفة، مثل إظهار معلومات وتنفيذ حسابات أو تخزين بيانات. واستمرارًا للمثال الموسيقي المناظر، فإن المُبَرمج يشبه المؤلف الموسيقي. وكما أن هذا الأخير يتصور الموسيقى ثم يصفها بالعلامات الموسيقية واحدة تلو الأخرى، كذلك فإن المُبَرمج يتخيل المسألة ثم يكتب البرمجيات تعليمة تلو أخرى.

 

وإلى هنا تتوقف المسايرة بين الموسيقى والبرمجيات، إذ يستخدم المؤلفون الموسيقيون الرموز والعلامات ذاتها بغض النظر عن كون الموسيقى المؤلفة هي لأغنية شعبية أو للحن أوپرالي. أما المبرمجون فلديهم ما لا يقل عن 500 لغة مختلفة تحت تصرفهم. بعض لغات البرمجة مثل كوبول COBOL تتوجه لمسائل في إدارة الأعمال، في حين تكون لغات أخرى مثل فورتران FORTRAN موجهة نحو المجالات الرياضياتية والعلمية. وتستخدم لغات مثل PL/I  لطيفٍ واسع من  التطبيقات.

 

إن توافر الكثير من اللغات المتنوعة، لكل منها هيكليتها وقواعدها البنيوية، هو أحد الأسباب العديدة التي تجعل تعداد الأسطر البرمجية صعبًا وغير موثوق. وبالتحديد لا يوجد قواعد عامة أو معايير لبيان ما يشكل بدقة سطرًا برمجيًّا في جميع لغات البرمجة. وبالنسبة إلى لغة جديدة مثل فيجوال بيسيك (البيسيك المرئي) Visual Basic، فإن مفهوم السطر ليس له مغزى يذكر؛ لأن المبرمجين يستخدمون على نحو نموذجي ما يسمى تعليمات التحكم البيانيةgraphical controls، إضافة إلى الكود البرمجي لتحديد الكيفية التي سيتصرف بها التطبيق البرمجي قيد التطوير. إضافة إلى ذلك، تستخدم أحيانًا عدة لغات في البرمجية ذاتها.

 

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

 

 

تناقض ظاهري محير

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

 

تؤدي حقيقة أن جزءًا مهمًّا من بناء تطبيقات كبيرة لا يرتبط مباشرة بعملية التكويد البرمجي، إلى تناقض مذهل [انظر الشكل في الصفحة 12]. لنفترض أن شركتين قررتا أن تنشئا برامج تقوم بالوظائف ذاتها تمامًا. ولنفترض أن إحداهما تستخدم لغة المجمِّع assembly. وهذا ما يتطلب عددًا كبيرًا من التعليمات لإنجاز مهام أساسية، مثل إضافة عدد إلى آخر. لنقل إنه بسبب انخفاض مستوى اللغة البرمجية هذه يتطلب التطبيق مثلاً مليون سطر برمجي. أما الشركة الأخرى فإنها تستخدم لغة كوبول، وهي لغة موجهة نحو إدارة الأعمال، وتحتاج إلى عدد أقل من التعليمات لتحقيق الوظائف ذاتها. ونظرًا لكون اللغة هذه ذات مستوى عالٍ فقد يحتوي البرنامج على 400000 تعليمة فقط. ويعطي هذا التعداد للأسطر البرمجية، الانطباع السطحي بأن البرمجية الأولى أكبر بما يزيد مرتين على البرمجية الأخرى، مع أن البرنامجين فعليًّا متماثلان.

 

تتعقد المقارنة أكثر إذا كان المبرمجون في الشركتين الافتراضيتين يكتبون الكودات البرمجية بنسب مختلفة (وهذا ما هو متوقع وإن كانت لديهم القدرات الأساسية ذاتها). وبسبب اختلاف اللغات البرمجية المستعملة، ربما يستطيع كل موظف في الشركة الأولى إنتاج 500 سطر برمجي كل شهر، في حين أن هذا الرقم قد ينخفض إلى 360 لدى الشركة الأخرى. ومع ذلك قد تستطيع الشركة الأخرى إنشاء هذا التطبيق بسرعة أكبر (1100 موظف – شهر مقابل 2000 لأن عدد الأسطر التي تُكتب أقل ولأن البرامج المكتوبة بلغة عالية المستوى تحتاج عادة إلى وقت أقل للتصويب، إضافة إلى أسباب أخرى. ونتيجة ذلك أن التكلفة الإجمالية للبرنامج قد تبلغ 20 مليون دولار لدى الشركة الأولى و11 مليون دولار لدى الشركة الأخرى. ولكن كل سطر برمجي لدى الشركة الأولى يكلّف 20 دولارًا يقابله 27.50 دولار لدى الشركة الأخرى. وبالتالي قد يبدو لأول وهلة أن مبرمجي الشركة الأولى أكثر إنتاجية من مبرمجي الشركة الأخرى، مع أن الشركة الأخرى تستطيع إنشاء التطبيق ذاته بسرعة أكبر وتكلفة أقل. لذا نجد أن انخفاض تكلفة السطر البرمجي لا يعبّر بالضرورة عن الكفاءة الاقتصادية.

 

ويتضح أن التعداد الأعمى للأسطر البرمجية قد يكون مضللاً. وقد أدرك علماء الحاسوب ذلك منذ سنوات خلت، وبالتالي بدأت عدة فرق بحثية في الشركة IBM (إحدى أكبر مؤسسات تطوير البرمجيات في العالم) باستكشاف توجهات أخرى لقياس البرمجيات. وقد لاحظت إحدى المجموعات، التي كنت عضوًا فيها، التناقض الإنتاجي في عام 1973، عندما قارنّا برمجيات مكتوبة بلغة المُجمّع ببرامج مكتوبة بلغة PL/I. وقد تبيّن أن الأولى تحتاج وسطيا إلى أربع مرات عدد التعليمات التي تحتاج إليها الأخرى، ولكن كلتا اللغتين يمكن تكويدهما بالمعدّل نفسه.

 

كان حلّنا المباشر لمسألة مقارنة التفاح بالبرتقال، وبكل بساطة، هو ضرب عدد أسطر برامج PL/I بـ 4 لتحويلها إلى عدد مكافئ من التعليمات في لغة المُجمِّع. ومع أن هذه الطريقة أعطت تكافؤا تقريبيًّا، فقد كانت أبعد ما تكون عن المثالية. وفي الواقع، فإننا لم نكن نقوم بأكثر من عملية مقايضة للعملات، أي كما لو أننا نحوّل دولارات إلى ينات yen.

 

يتطلب التحليل الاقتصادي للبرمجيات طريقة مناسبة لقياس حجم البرامج الحاسوبية وإلا ستكون النتائج مضللة. لنأخذ تطبيقًا واحدًا أنشئ بلغتين برمجيتين مختلفتين، لغة المُجمّع ولغة كوبول، علمًا أن اللغة الأولى تتطلب جهدًا أكبر وبالتالي تؤدي إلى تكلفة أعلى (a). وإذا قيست البرمجية بتعداد الأسطر في الكود البرمجي، يبدو حجم النسخة المكتوبة بلغة المُجمّع أكبر مرتين من حجم البرنامج المقابل لها بلغة كوبول (b)، مع أن كليهما يقوم بالمهام ذاتها. وهذا التشويه يجعلنا نظن أن إنتاجية مشروع لغة المُجمّع أعلى (c) وذات جدوى مالية أفضل (d). ولكن إذا قيست البرمجيات بالنقاط الوظيفية التي تدلّ على إمكانية البرنامج [انظر الشكل في أعلى الصفحة المقابلة]، يظهر أن البرنامجين متساويان من حيث الحجم (e) مما يعطي صورة أصدق للإنتاجية (f) وللتكلفة (g).

 

هدف النقاط الوظيفية

باشر باحثون آخرون لدى الشركة IBM في وايت پلينز بنيويورك، وفي أمكنة أخرى، بخطة بحث أكثر تعمقًا. وقد قرّر <A. آلبريشت> وزملاؤه أن يصيغوا وحدات تعقيد البرمجيات software complexity التي سموها «نقاطا وظيفية». وقد صمَّموا هذه الطريقة الجديدة للمحاسبة لتكون مستقلة عن لغات البرمجة.

 

لحساب النقاط الوظيفية، تُفْحَص خمس خصائص للبرنامج: المُدْخلات والمُخْرجات والاستفسارات التفاعلية (التحاورية) (عندما يُوَجّه المُستَخدِم استفسارًا ويجيبه الحاسوب) والملفّات المنطقية الخارجية (الواجهات الاتصاليةinterfaces) والملفّات المنطقية الداخلية. لنأخذ مدققًا إملائيًّا spell checker له مدْخل وحيد (اسم الملف المراد فحصه) وثلاثة مُخرجات (العدد الكلي للكلمات المستعرضة وعدد الأخطاء المكتشفة ولائحة بالكلمات الخاطئة) واستفسار واحد (يستطيع المُستخدِم أن يحصل تفاعليًّا على عدد الكلمات المعالجة حتى لحظة الاستفسار) وملف خارجي واحد (الوثيقة المراد فحصها) وملف داخلي واحد (المعجم). إن عدد عناصر هذا البرنامج البسيط هو 1+ 3 + 1 + 1 + 1 = 7.

 

يتبين عمليا أن تحليل النقاط الوظيفية أكثر تعقيدًا من مجرد عدّ خمسة أنواع من الخصائص. ويستخدم ممارسو هذه الطريقة أوزانًا weights مختلفة لحساب التعقيد (منخفض ومتوسط وعال) بالنسبة إلى كل عنصر حسب الإرشادات المفصّلة المتابعة من قبل المجموعة الدولية لمستخدمي النقاط الوظيفية International Function Point Users Group  IFPUG  ، وهي منظمة موجودة في ويسترڤيل بولاية أوهايو. فالحسابات الفعلية متشعبة كثيرًا، ولكن المجموع الموزّن weighted للنقاط الوظيفية بالنسبة إلى المثال السابق (مدقق إملائي بسيط) هو 40، وذلك إذا افترضنا أن كلاًّ من عناصره السبعة هو متوسط التعقيد.

 

أخيرًا يُزاد أو يُنقَّص مجموع النقاط الوظيفية بوساطة مُضاعف multiplierليتلاءم مع التعقيد الملاحظ للنظام ككل. ويعتمد هذا التصويب على 144 عاملاً، يدخل ضمنها، مثلاً، إذا كانت معالجة التطبيق ستوزع على حواسيب مختلفة وأيضًا إذا كانت هناك أجزاء من البرمجيات تحتاج إلى تصميم يأخذ بعين الاعتبار إعادة استخدامها في برامج مستقبلية [انظر ما هو مؤطر في الصفحة 14].

 

إن حساب النقاط الوظيفية للبرمجيات المعقّدة أمر معقد إلى حدّ ما، ويحتاج عمومًا إلى مختصين نجحوا في امتحانات الاعتمادية (التأهيل) certification. ولا يحتاج معظم مديري البرمجيات إلى معرفة الآلية الفعلية لحساب النقاط الوظيفية، ولكن عليهم جميعًا أن يستوعبوا تقويم الإنتاجية والجودة التي يُعبَّر عنها حاليًا بهذه القياسات.

 

توفر النقاط الوظيفية وسيلة لتقدير حجم برنامج وفقًا لإمكاناته. يتطلب القياس فحص خمس صفات لتطبيق ما: مُدْخلاته ومُخْرجاته والاستفسارات التفاعلية والملفات الخارجية والملفات الداخلية. وعدد هذه العناصر بالنسبة إلى مدقق إملائي بسيط هو سبعة، وكل منها يجب أن يُعطى وزنًا يتناسب مع تعقيده. ويُزاد أو يُنقَّص مجموع النقاط الوظيفية ليتلاءم مع التعقيد الملاحظ للبرنامج ككل، وذلك حسب 14 معيارًا [انظر ما هو مؤطر في الصفحة 14]. ويدل المجموع النهائي على المستوى الوظيفي والتعقيدي للتطبيق.

 

إن حجم البرمجيات لبرامج نموذجية، مثل معالجات الكلمات ونظم التشغيل، يمكن مقارنتها بوساطة النقاط الوظيفية. والنظم الدفاعية الرئيسية هي أكبر أنواع التطبيقات حيث تحوي 300000 نقطة وظيفية (نحو 27 مليون سطر من الكودات البرمجية).

 

تشكل النقاط الوظيفية أدق أسلوب لمقارنة البرمجيات بسبب استقلاليتها عن لغة البرمجة المستخدمة. ففي المثال السابق التناقضي، لو افترضنا أن كلا التطبيقين، أحدهما في لغة المُجمّع والآخر في لغة كوبول، يحتويان على 4000 نقطة وظيفية (لأن وظائفهما متماثلة تكون النقاط الوظيفية متساوية)، تكون التكلفة الكلية لكل نقطة وظيفية هي 5000 دولار بالنسبة إلى الشركة الأولى و2750 بالنسبة إلى الشركة الأخرى [انظر الشكل في الصفحة المقابلة]. ويعطي هذا المثال صورة أوضح عن الاقتصاديات الفعلية للمشروعين.

 

يستطيع مديرو الشركات، باستخدام النقاط الوظيفية، إجراء تحليلات أكثر وثوقية عن الإنتاجية والجودة. وفي الوقت الحالي فإن هذه المنهجية هي الأكثر استخدامًا في مثل تلك الدراسات في الولايات المتحدة الأمريكية ومعظم أوروبا. كما أن العدد الإجمالي للمشروعات البرمجية على نطاق العالم بأسره التي تُستخدم فيها النقاط الوظيفية يزيد على 100000. وقد استخدمت وزملائي، من بين آخرين، معلومات مستمدّة من هذه الدراسات لفحص التغيرات في الإنتاجية والجودة حسب البلد والصناعة ولغة البرمجة.

 

وقد أدت هذه الاستقصاءات إلى استنتاج قواعد عملية تقريبية تساعد الشركات على إنشاء وتطوير البرمجيات، خاصة قبل المباشرة بمشروعات كبيرة. (إذا كانت البرمجيات موصفة بالكامل قبل البدء بالعمل، يمكن حساب العدد الإجمالي للنقاط الوظيفية للمشروع قبل كتابة سطر واحد من الكودات). وعلى سبيل المثال فإن رفع مجموع النقاط الوظيفية لأي نظام إلى القوة 125 يعطي تقديرًا أوليًّا لعدد الأخطاء التي يجب تصحيحها. كما أن تقسيم عدد النقاط الوظيفية على 150 يعطي تقديرًا لعدد المبرمجين ومحللي البرمجيات والفنيين اللازمين لإنشاء هذا التطبيق. كذلك فإن رفع مجموع النقاط الوظيفية إلى القوة 0.4 يعطي تقديرًا أوليًّا للزمن اللازم بالأشهر لإنجاز المشروع من قبل فريق العمل. ومن الواضح أن هذه القواعد العملية لا تغني عن التقديرات التفصيلية الرصينة ولكنها تعطي أرقامًا أولية يمكنها معالجة الجداول الزمنية غير الواقعية والمفرطة في التفاؤل، وهي مشكلات شائعة في التطوير البرمجي.

 

على الرغم من هذه المعلومات المفيدة، فإن الحقيقة المؤسفة هي أن معظم المؤسسات لا تجري أي قياسات برمجية مفيدة على الإطلاق. ومع أنه قُدر حجم أكثر من 100000 مشروع باستخدام النقاط الوظيفية حتى الآن، فإن ذلك لا يمثل أكثر من واحد في المئة من مجموع التطبيقات البرمجية قيد الاستخدام. ففي الشركات الصغيرة، وخاصة تلك التي لا يتجاوز عدد المختصين بالبرمجيات فيها المئة، ليس هناك تقنية قياس شائعة، لا النقاط الوظيفية ولا غيرها. ولكن استخدام النقاط الوظيفية أصبح شائعًا لدى الشركات الكبيرة التي يزيد عدد العاملين في إنشاء البرامج الحاسوبية واختبارها وصيانتها على 10000 شخص، إذ تشكل البرمجيات بالنسبة إلى مثل هذه المؤسسات تكلفة مهمة تتطلب قياسات وتقديرات دقيقة.

 

ومن المفيد أيضًا النظر في حجم التطبيقات البرمجية الشخصية. فمعالج الكلمات الذي استخدمته لكتابة هذه المقالة يحوي نحو 435000 سطر في الكودات البرمجية، وفيه نحو 3500 نقطة وظيفية. وخلال العمل اليومي قد يستخدم موظف ما برمجيات يزيد مجمل نقاطها الوظيفية على 25000 نقطة، وذلك على شكل برمجيات صحائف جدولية ومعالجات كلمات وتطبيقات تعتمد على قواعد بيانات وأدوات إحصائية وبرامج خاصة. تنفذ جميع هذه التطبيقات تحت سيطرة نظم تشغيل يزيد عدد نقاطها الوظيفية على 100000 نقطة.

 

ملء بطاقة إحراز النقاط

إن منهجية النقاط الوظيفية تسمح للمحلِّلين بالحكم على مدى تعقد برنامج حاسوبي باستخدام 14 معيارًا. إن التقدير الفعلي، الذي يتطلب أشخاصًا اتبعوا تدريبًا خاصًّا ونجحوا في امتحان الاعتمادية (التأهيل) هو إجراء مفصّل في إرشادات وصّفتها المجموعة الدولية لمستخدمي النقاط الوظيفية (IFPUG)، الموجودة في ويسترڤيل بولاية أوهايو. واللائحة التالية تعطي العوامل الأربعة عشر، ويقابل كل منها مثالاً لبرنامج يحظى بنقاط عالية لهذا العامل. 1. اتصالات بيانات معقدة: برنامج لمصرف (بنك) متعدد الجنسيات يتعامل مع تحويلات نقدية إلكترونية من مؤسسات مالية في جميع أنحاء العالم. 2. معالجة موزعة: آلة بحث على الويب تقوم بمعالجة أكثر من 12 حاسوبًا مُخدما server تعمل ترادفيا. 3. أهداف أداء صارم: نظام مراقبة/ تحكم في الطيران عليه تزويد المراقبين باستمرار بمعلومات آنية ودقيقة عن مواقع الطائرات اعتمادًا على بيانات الرادار. 4. تركيبة عالية الاستخدام (مُثقلة بالاستخدام): نظام جامعي يسجل مئات الطلبة في وقت واحد. 5. معدلات عالية لتنفيذ الصفقات: برنامج مصرفي عليه إنجاز ملايين الصفقات ليلاً لموازنة الدفاتر المالية قبل يوم العمل التالي. 6. الإدخال الفوري on-line للبيانات: برنامج  الموافقة على رهن بيوت، حيث يقوم الموظفون بإدخال البيانات تفاعليًّا (تحاوريًّا) في نظام حاسوبي اعتمادًا على طلبات ورقية (خطية) مملوءة من قبل مالكي بيوت مرتقبين. 7. تصميم حميمي للمستخدم user-friendly: برمجيات لأكشاك Kiosks حاسوبية مع شاشات حساسة للمس تسمح للمستهلكين في محطة قطارات الأنفاق (المترو) بشراء تذاكر باستخدام بطاقات تسليف خاصة بهم. 8. التحديث الفوري للبيانات: نظام حَجْز لشركة طيران يسمح للمكاتب السياحية بالقيام بحجوزات على الرحلات الجوية المختلفة والحصول على مقاعد محددة. يجب على البرمجيات أن تكون قادرة على تثبيت ومن ثم تعديل بعض التسجيلات في قاعدة البيانات للتأكد من عدم بيع المقعد مرتين. 9. معالجة مُعقّدة: برمجية طبية تستقبل الأعراض المختلفة للمريض وتقوم بإجراء محاكمات منطقية متشعبة وصولاً إلى تشخيص أولي. 10. إعادة الاستخدام: معالج كلمات مصمّم بحيث يمكن دَمْج شرائط أدوات لوحة الخيارات في تطبيقات أخرى، مثل صحيفة جدولية أو مولّد تقارير report generator. 11. سهولة التركيب: تطبيق للتحكم في تجهيزات يمكن لغير المختص أن يقوم بتركيبه في معدات الحفر النفطية بالمناطق البحرية. 12. السهولة العملياتية: برنامج تحليل أعداد هائلة من السجلات المالية المتراكمة (التاريخية) يقوم بمعالجة المعلومات بطريقة تقلّل عدد المرات التي يقوم مشغلو الحاسوب بفك وإعادة تركيب الأشرطة tapes المختلفة التي تحوي البيانات، إلى حدها الأدنى. 13. تعدّد المواقع: برمجيات رواتب وأجور لشركة متعددة الجنسيات عليها الأخذ بعين الاعتبار الخصائص المميزة لبلدان شتى، بما فيها اختلاف العملات وقواعد حساب ضرائب الدخل. 14. المرونة: برنامج تنبئي مالي يستطيع إصدار تصورات شهرية أو ربع سنوية أو سنوية مُكيّف وفق حاجة مدير أعمال محدّد، يمكنه طلب تحليل المعلومات حسب مناطق جغرافية معينة وخطوط إنتاج.

 

مقياس لا يرقى إلى حدّ الكمال

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

 

كذلك احتجّ بعض الباحثين؛ لأن حساب النقاط الوظيفية يتطلب جهدًا بشريًّا كبيرًا. وهذا النقد مبرّر، لكن أدوات العدّ الآلي قد تخفف هذا العبء. وأفاد آخرون أنه نظرًا لأن طريقة النقاط الوظيفية طُوِّرت لنظم معلومات إدارة الأعمال، فإنها غير مناسبة لتقدير أنواع أخرى من البرمجيات. ولكن النقاط الوظيفية ساعدت على قياس برمجيات النظم، وتطبيقات مبيّتة (مبرمجة بشكل دائم) ضمن أدوات المستهلك وأسلحة عالية التقانة. كما أن المحترفين الحاسوبيين يراجعون بشكل دائم قواعد النقاط الوظيفية لتشمل برمجيات من أنماط حديثة، مثل تطبيقات الشبكة العنكبوتية العالمية (الويب).

 

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

 

قد يكون موضوع التقييس standardization هو التحدي الأكبر. وقد اعترض العديد من العاملين في مجال البرمجيات على بعض إجراءات العدّ في التوجه الأصلي للشركة IBM، وأيضًا على الطريقة الحالية الموضوعة من قبل المجموعة الدولية لمستخدمي النقاط الوظيفية. ونتيجة لذلك فهنالك الآن نحو 20 شكلاً مغايرًا لهذه التقنية.

 

وفي بداية الثمانينات طوّر <R .Ch. سايمونز> (وهو باحث لدى نولان ونورتون وشركاهما في لندن) أسلوبًا لعدّ النقاط الوظيفية سمي Mark II. وأحد التعديلات التي أدخلها الأسلوب Mark II هو توسيع عدد عوامل التسوية (الضبط) adjustment factors من 14 إلى 19 عاملاً. وهناك تعديل آخر، يسمى النقاط العلاّمة feature points، موجّه إلى التطبيقات الهندسية والعلمية. إذ إن استخدام النقاط الوظيفية التقليدية يمكن أحيانًا أن يؤدي إلى تقدير منخفض؛ لأن مثل هذه البرمجيات معقد جدًّا على الرغم من أن عدد المُدْخلات والمخرجات قليل جدًّا. لذا يأخذ أسلوب النقاط العلاّمة عدد الخوارزميات في البرنامج بعين الاعتبار ويخفّض عدد عوامل التسوية من 14 إلى ثلاثة فقط. وثمة تفريعات أخرى لهذا الأسلوب تشتمل على ما يسمى النقاط الوظيفية الثلاثية الأبعاد D-3 والنقاط الوظيفية الهندسية والنقاط الهدف والنقاط الوظيفية الكاملة.

 

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

 

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

 

 المؤلف

Capers Jones

علمي رئيسي ونائب تنفيذي لرئيس شركة Artemis Management Systems في بولدر بولاية كولورادو الأمريكية، والتي تملكت حديثًا شركة Software Productivity Research في بولينگتون بولاية ماساتشوستس، وهي شركة استشارات كان قد أسسها. وهو مصمّم عدة وسائل لتقدير تكلفة وجودة البرمجيات ومؤلف 11 كتابًا عن إنتاجية المُبَرمِج وجودة البرمجيات. وكان جونز مديرًا مساعدًا في المركز التقاني للبرمجة التابع للشركة ITT في ستراتفورد بولاية كونتيكت. وقبل الالتحاق بالشركة ITT عمل لدى الشركة IBM لمدة 12 سنة حيث حصل على جائزة الإسهام المميز لعمله في مجال جودة البرمجيات وإنتاجية المُبَرمج.

مراجع للاستزادة 

AD/M PRODUCTIVITY MEASUREMENT AND ESTIMATE VALIDATION. Allan Albrecht. IBM Corporation, Purchase, N. Y, May 1984.

SOFTWARE SIZING AND ESTIMATING: MK II FPA (FUNCTION POINT ANALYSIS). Charles R. Symons. John Wiley & Sons, 1991.

IFPUG COUNTING PRACTICES MANUAL. RELEASE 4. International Function Point Users’ Group, Westerville, Ohio, April 1995.

METRICS AND MODELS IN SOFTWARE QUALITY ENGINEERING. Stephen H. Kan. Addison-Wesley, 1995.

APPLIED SOFTWARE MEASUREMENT: ASSURING PRODUCTIVITY AND QUALITY. Second edition. Capers Jones. McGraw-Hill, 1996.

FUNCTION POINT ANALYSIS: AN EMPIRICAL STUDY OF ITS MEASUREMENT PROCESSES. A. Abran and P. N. Robillard in IEEE Transactions on Software Engineering, Vol. 22, No. 12, pages 895-909; December 1996.

Scientific American, December 1998

 

(*) Sizing Up Software

(1) software، أو برامجيات.