تحليل نقطة الوظيفة - تقنية مبالغة في تقديرها بشكل خطير؟

Question

توضيح المكافأة

أعلم أنه سؤال شخصي.الإجابة المثالية التي أبحث عنها هي الإجابة التي تشرح لماذا سيكون السيناريو المقتبس هنا مفاجئًا للغاية.

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

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

---

أعلم أن الأسئلة حول فبا قد تم طرحها عدة مرات من قبل، ولكن هذه المرة سأتناول الأمر من زاوية تحليلية أكثر، مدعومة بالبيانات.

1.أولا، بعض البيانات

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

في النهاية هو حساب FP غير المعدل يكون 99.

هناك آخر مقالة عن InformIT مع بيانات الصناعة في الساعة النموذجية/FP.يتراوح من ساعتين/FP إلى 27.4 ساعة/FP.دعونا نحاول التمسك بها 2 في الوقت الحالي (نظرًا لأن قراء SO هم على الأرجح الحشد الأكثر كفاءة :p).

2.التحقق من الواقع!؟

الآن فقط تحقق من لقطات الشاشة مرة أخرى.

قم بالقليل من الرياضيات هنا

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

بجد؟هل سيستغرق تنفيذ هذا النموذج 5 أسابيع؟هل هو مجرد شعوري بأن الأمر لن يستغرق أي مبرمج لائق أكثر من أسبوع واحد (أنا لا أقول حتى عطلة نهاية الأسبوع) لاستكماله؟

الآن دعونا نحاول تقدير تكلفة المشروع.سنستخدم الحد الأدنى للأجور في نيويورك في الوقت الحالي (ويكيبيديا)، وهو 7.25 دولار

198 * 7.25 = $1435.5

مما يمكنني رؤيته من لقطات الشاشة، هذا التطبيق عبارة عن تطبيق صغير لتحسين برنامج Excel.كان بإمكاني شراء MS Office Pro مقابل 200 دولار، مما يمنحني قدرًا أكبر من إمكانية التشغيل التفاعلي (ملفات .xls) والمرونة (جداول البيانات).

(للتسجيل، يحتوي موقع الويب نفسه على مقالة أخرى تناقش الإنتاجية.يبدو أنهم يستخدمون عادةً 4.2 ساعة/FP، مما يمنحنا إحصائيات أكثر صادمة:

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

(هذا حتى على افتراض أن جميع المبرمجين الفقراء لدينا يحصلون على الحد الأدنى للأجور!)

3.نسيت شيئا ما هنا؟

الآن يمكنني أن أتوصل إلى عدة تفسيرات محتملة:

1. إن FPA مناسب حقًا فقط للمشاريع الأكبر (1000+ FPs) لذا يصبح غير دقيق للغاية على نطاق أصغر.
2. يتقلب مقياس الساعات/FP بشكل مفاجئ من فريق إلى فريق، ومن مشروع إلى مشروع.بالنسبة لمشروع صغير مثل هذا، كان بإمكاننا استخدام ما يقرب من 0.5 ساعة/FP أو شيء من هذا القبيل.(الآن هذا النوع يجعل عملية التقدير برمتها بلا معنى، إلا إذا كانت شركتي تنفذ نفس النوع من المشاريع لعدة سنوات مع نفس الفريق، وهو أمر غير شائع حقًا.)

من تجربتي مع العديد من مقاييس البرامج، فإن Function Point ليس مقياسًا خفيف الوزن.إذا كان شيء الساعة/FP يتقلب كثيرًا، فما هو المغزى، ربما كان بإمكاني استخدام نقاط قصة المستخدم التي هي أسرع كثيرًا في الحصول عليها ويمكن القول أنها غير مؤكدة تقريبًا.

ماذا ستكون إجابات خبراء FP على هذا؟

Answer 1

منذ حوالي عشر سنوات ، أعطاني صديق شرب لي قطعة رائعة حقًا من الحكمة. في أي استشارة مشروع ، اطرح ثلاثة أسئلة: 1. ما هي المشكلة التي نحاول حلها؟ 2. ما هي التسليمات؟ 3. كيف سنعرف متى ننتهي؟ وأضاف أنه لا ينبغي للمرء أبدًا أن يأخذ أي مشروع لم يتم الإجابة على أي من الأسئلة قبل بدء المشروع.

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

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

Answer 2

هل هو مجرد شعوري بأنه لن يتطلب أي مبرمج لائق أطول من أسبوع واحد (لا أقول حتى عطلة نهاية الأسبوع) لإكماله؟

يميل المطورون دائمًا إلى التقليل من الوقت الذي يستغرقه الأمر لإنهاء شيء ما. يعتقدون أنه لن يكون هناك أي أخطاء ، ولا تغييرات في المتطلبات ، ولا شيء لم يفعلوه من قبل ويتعين عليهم قضاء أيام في اكتشافها.

من ما يمكن أن أراه من لقطات الشاشة ، هذا التطبيق عبارة عن تطبيق صغير لتحسين Excel. كان بإمكاني شراء MS Office Pro مقابل 200 دولار مما يمنحني قابلية التشغيل البيني (ملفات .xls) والمرونة (جداول البيانات).

هل تقارن سعر البرامج المخصصة تمامًا بالبرنامج الذي يبيع ملايين النسخ؟ بشكل جاد؟

Answer 3

والحقيقة هي أن معظم طرق تقدير البرامج تقلل فعليًا ، على الرغم من أنه في البداية ، يبدو أنه غير بديهي. لقد عملت ذات مرة في شركة حيث كانت 300 سطر من الكود لكل شهر شهرًا يعتبر تقديرًا كبيرًا ، وفي معظم الأشهر التي وصلنا إليها في 200-250. ولكن دعنا نذهب مع 200. هذا هو 10 أسطر من الكود في يوم العمل. من لا يستطيع كتابة 10 أسطر من التعليمات البرمجية في يوم عمل؟ هيا! يمكنني كتابة 50 إلى 100 سطر أو أكثر من الكود في يوم جيد! ومع ذلك ، فإن الشركات التي تستخدم أرقامًا كهذه تكمل مشاريعها مرارًا وتكرارًا في الجدول الزمني وتجاوز الميزانية. لماذا هذا؟ حسنًا ، زحف النطاق ، كما يوحي مايكل بورغواردت ، هو واحد كبير. ولكن دعونا نمنع ذلك من الصورة لمدة دقيقة ، ونفترض أن العميل والعميل حصلوا عليها بشكل صحيح في المرة الأولى. لماذا تقدر الشركة 10 أسطر فقط من الكود يوميًا؟

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

هذا هو كل هندسة البرمجيات اليومية التي يمكنني سحبها من أعلى رأسي في 3 دقائق ، أنا متأكد من أنني فاتني المزيد ، لكن هل يساعد ذلك في الحصول على صورة أكثر اكتمالا من أين تأتي هذه التقديرات؟

Answer 4

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

وجهة نظري في هذه المرحلة هي أنها ستكون من أعلى إلى أسفل "ترتيب الحجم" لتكملة التقدير من أسفل إلى أعلى. من الجيد دائمًا أن يتم تطبيق أكثر من تقنية تقدير للمساعدة في التحقق من صحة أن الأرقام التي يتم الوصول إليها في "Hold Up".

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

Answer 5

أنا شخصياً وجدت FPA مضللاً ...بدءًا.

ما لم يكن لديك بيانات FPA تاريخية للمشاريع السابقة، فمن المؤكد أن FPA يمكن أن ينتهي الأمر بالمبالغة في تقدير الأمر برمته، باستخدام معايير الصناعة.

تعلمت أن VAF هو مؤشر جيد لاستخدامه عند التعامل مع FPA.على الرغم من أنه يمنحك نطاق تباين بنسبة 35% في عدد FP الخاص بك، فمن الذي يمنع المحلل/مدير المشروع من تحويل هذا إلى تباين بنسبة 50%.

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

لذلك أود أن أقول أنه إذا استخدمت أفضل سيناريو للحالة وهو -35% على العد غير المعدل، فستصل إلى عدد FP المعدل وهو ~64.يمنحك ما يقرب من 3 أسابيع ونصف من التقدير.من خلال التجربة، أود أن أقول إن تطبيقًا من هذا النوع يمكن إجراؤه في وقت أقرب من ذلك بكثير، ولكن أي اختبار شامل وتصحيح الأخطاء والتوثيق والأعمال الورقية الأخرى من شأنه أن يمتد إلى أبعد من ذلك وتأخذ FP ذلك في الاعتبار.من المحتمل جدًا أن يقوم فريقك بعمل FP/ساعة واحدة.وفقًا للمعايير العادية، يمثل الترميز والاختبار 25% من عدد FP، لذلك في هذه الحالة حتى مع أخذ رقمك البالغ 99 إطارًا في الثانية، فإن جزء الترميز والاختبار سينخفض ​​إلى 25 إطارًا في الثانية، وهو أمر أكثر قابلية للفهم نظرًا للموقف.

ما رأيته أيضًا في الممارسة العملية هو أن بعض الشركات قد ابتكرت جداول التعقيد الخاصة بها، لذلك إذا كانت 3 RETs و10 DETs تعني متوسط ​​التعقيد لشركة واحدة، فإن شركة أخرى ستصنفها على أنها منخفضة التعقيد.وهذا من شأنه أن يؤثر إلى حد كبير على عدد FP النهائي.

لذا استخدم أداة FP كدليل واجمع أكبر قدر ممكن من البيانات للمشروعات السابقة قبل أن تبدأ فعليًا في الاعتماد على FPA لتحديد تقديرات التكلفة والوقت.

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

آمل أن يكون سنتي 2 مفيدًا لك.

Answer 6

في شركتي السابقة ، كنا قد حسبنا من هذا القبيل - خاصة إذا كان هناك شخص ما يريد لدفع ثمنها ؛)

Answer 7

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

بطريقة ما ، يجب أن نقول أن FP مفيد للمشاريع المتوسطة إلى الكبيرة ، حيث يتجاوز 350-400 إطارًا في الثانية.

Answer 8

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

Answer 9

توصيل القيم من المثال الذي استشهد به في آلة حاسبة نقطة الوظيفة عبر الإنترنت هذه (http://developergeeks.com/functionpoint.aspx) ، التي تحسب FPs المعدلة وتأخذ في الاعتبار عوامل الترجيح الأخرى المختلفة ، أحصل على النتائج التالية ، بافتراض معدل إنتاجية قدره 2 إطارًا في الساعة منذ أن يكون النظام في المثال بسيطًا للغاية:

1. FPS المعدل: 42.9
2. الشخص المقدر أشهر: 0.54

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

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

Answer 10

من تجربتي مع العديد من مقاييس البرامج ، فإن PONSTION POINT ليست في الحقيقة مقياسًا خفيف الوزن. إذا كان الشيء الذي يتقلب عليه الساعة/FP ، فما هي النقطة ، فربما كان بإمكاني الذهاب مع نقاط قصة المستخدم التي هي أسرع بكثير من أجل الحصول عليها ويمكن القول أنها غير مؤكدة تقريبًا.

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

Answer 11

هذه المناقشة مضللة تمامًا ، لأن السؤال يفترض بالفعل أن FPA هو تقنية تقدير الجهد. ليس.

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