تتناول هذه المقالة طريقة استخدام 1C DSS (نظام تصميم التطبيقات) لتقييم مدة وتكلفة المشاريع باستخدام طريقة COCOMOII.
كيف تبرر العميل أن تقييمك لتوقيت المشروع موضوعي؟
كيف يمكن قياس هامش المشروع قبل البدء ، في مرحلة ما قبل البيع؟
كيفية تقييم نطاق التداول بسعر المشروع من أجل منع الخسارة؟
كيف يتم حساب موضوعي الحاجة إلى مشروع لأعضاء الفريق الذين ليسوا مطورين (محللي الأعمال ، وعلماء المنهج ، والكتاب التقنيين ، وما إلى ذلك) ، وكيفية إضفاء الطابع الرسمي على نتيجة أعمالهم بأكثر الطرق البسيطة وبأسعار معقولة؟جدول المحتويات
- مقدمة.
- المشكلة الرئيسية لاستخدام 1C DSS في الوقت الحالي.
- لماذا كومكومي؟
- لماذا 1C DSS؟
- دورة CoCOMOII الأقصر
- الانتقال من تقييم العمل للمطورين إلى تقييم العمل للمحللين وعلماء المنهجيات
- الزائفة رمز.
- 1 DSS والرمز الزائف.
- ملخص
دخول
تم إطلاق نظام تصميم التطبيقات 1C في السوق منذ 6 سنوات ، وفي يوليو 2019 نما إلى الإصدار 2. استنادًا إلى تقنيات SADT ونموذج تطوير متتالي. ومع ذلك ، فإنه يسمح لك بقيادة التنمية سكروم / رشيقة في المراحل الفردية.
مصمم للمشاريع الطويلة المعقدة التي ينفذها فريق متعدد المكونات مع استبدال الموظفين بشكل متكرر. ويشمل وظائف إدارة المشروع ، ووصف العمليات التجارية ، وتصميم بنية ووظائف أنظمة المعلومات ، وتطوير البرمجيات وصيانة IP ، وكذلك الاختبار التلقائي على أساس Vanessa / Gherkin.
أولاً وقبل كل شيء ، من المفيد لمكاملي النظم وأصحاب الامتيازات ، وثانياً لجميع المؤسسات التي تجري عمليات تطوير وصيانة مستقلة لعناوين IP الخاصة بها بمشاركة فناني الأداء الخارجيين.
المشكلة الرئيسية لاستخدام 1C DSS في الوقت الحاضر
المشكلة الرئيسية لاستخدام 1C DSSR في الوقت الحاضر (الإصدار 1 يستخدم بشكل رئيسي) هي الاستخدام غير الصحيح للغاية 1C DSS كتقنية.
غالبًا ما يتم استخدام 1C DSS على مستوى الوظائف المخصصة للمطورين ، وفي أفضل الأحوال للمهندسين المعماريين. غالبًا ما يكمن دورها في وصف وتطوير "وظائف" النظام وتشكيل المهام للمبرمجين. هذا هو خطأ النهج للعمل مع DSS.
تقوم الأنظمة الموجودة في السوق (JIRA ، إلخ) بعمل رائع في تحديد المهام للمبرمجين ومعالجة تذاكر المستخدم. مع هذا الاستخدام ، يمتلك مطورو DSS وظيفة إضافية بيروقراطية إضافية تستغرق وقتًا ، وتستغرق وقتًا من الترميز "الخالص".
يصبح المطور ملزماً بوصف وظيفة النظام المطبق / النهائي من أجل ضمان تحديد المهام للمبرمجين الذين لديهم روابط لكائنات البيانات الأولية ("لغة مشتركة" من حيث إريك إيفانز في عمله "التصميم الموجه للكائنات (DDD). هيكلة أنظمة البرمجيات المعقدة").
في الوقت نفسه ، يتم تجاهل مهام النصف الآخر من فريق المشروع - مديري المشاريع ، ومحللي الأعمال ، وعلماء المنهجيات بالكامل تقريبًا. لسوء الحظ ، يمكننا القول أنه حتى 1C نفسها في الإصدار 2.0 من DSS قلصت إلى حد كبير وظائف هذه الفئة من المشاركين ، مما أدى إلى تغيير كبير في نموذج DSS مقارنةً بالإصدار 1.0 تجاه المطورين والمختبرين (على سبيل المثال: تمت إزالة المتطلبات وكائنات البيانات بشكل صريح).
ومع ذلك ، فإن مسألة الاستخدام الكامل والكامل لنظام DSS حادة. في هذه المقالة ، على وجه الخصوص ، سننظر في كيفية استخدام تقنية تقدير شروط وتكاليف المشاريع باستخدام طريقة COCOMOII في 1C DSS.
الكل يريد أن يعرف كم من الوقت يمكن إكمال المشروع ، والذي لا يمكن للعميل نفسه أن يقول ما يريده في النهاية ، وإلى أي مدى يمكن التفاوض مع العميل؟
وكيف تقنع العميل بأن الوقت والتكلفة المقترحة لهما ما يبرره؟ ومع ذلك ، فإن هذا الأخير ليس ضارا لمعرفة لأنفسنا.
والأهم من ذلك ، كيف يتم حساب موضوعي الحاجة إلى مشروع لأعضاء الفريق الذين ليسوا مطورين (محللي الأعمال ، وعلماء المنهجيات ، والكتاب التقنيين ، وما إلى ذلك) ، وكيفية إضفاء الطابع الرسمي على نتيجة عملهم بأكثر الطرق البسيطة وبأسعار معقولة؟
لماذا كومكومي؟
يفضل العملاء في أي صناعة أن يكون لديهم تقييم موضوعي ومعقول ومقبول بشكل عام لتكلفة وتوقيت المشروع. إنهم يرغبون في رؤية صلة مشروعهم بتجربة أحد مدمجي النظم في المشاريع السابقة. في الوقت نفسه ، لدى عميل نادر فكرة واضحة عن النتيجة النهائية للمشروع ، ولكن في المشروعات التي تطور نموذجًا مفاهيميًا ، فإنها لا تفعل ذلك بالتأكيد. وليس لديه تكامل النظام.
كيفية تقييم الوقت والتكلفة في مرحلة ما قبل البيع في غياب المعلومات؟ وفي سياق المشروع ، مع مراعاة التغييرات (آفة جميع المشاريع)؟
تتيح لك طريقة COCOMOII إجراء مثل هذا التقييم ، مع الأخذ في الاعتبار الخبرة المتراكمة لمكامل النظام ، وبأبسط الطرق ، بينما على الفور ، أثناء المشروع ، وضع مواصفات السعر / التوقيت وتبريرها للاتفاق مع العميل.
لماذا 1C DSS؟
الشيء هو أن 1C DSS يعتمد على SADT وتقنيات "اللغة العامة" (هذا موصوف بمزيد من التفصيل في مقالتي المنفصلة). إن SADT هي التي تدمج عملية النمذجة مع عملية التطوير القائمة على "اللغة المشتركة". تتيح لك "اللغة العامة" الحصول على أساس لحساب مؤشرات المصطلحات المقدرة.
دورة CoCOMOII الأقصر
نشأت تقنية COCOMO في عام 1963 استجابة للحاجة إلى تقييم سريع وغير معقد لتعقيد وتوقيت تطوير منتجات البرمجيات في المشاريع القادمة. أساس نموذج COCOMO و مرحلته التالية ، COCOMOII ، هو عدد أسطر رمز البرنامج (KSLOC عبارة عن ألف سطر من الكود المنطقي ، أي أسطر الكود التي تعبر عن العملية). هذا الأساس هو نتيجة أي مشروع لتطوير البرمجيات ، إنه نوع من الجوهر للمشروع.
(سنضع في اعتبارنا أن COCOMO يختلف عن COCOMOII في أنه يتم استبدال المعلمات العددية لصيغة COCOMO بجدول معلمات COCOMOII ، لكن جوهر الطريقة يبقى كما هو).
وبالتالي ، بعد امتلاك الأمتعة المتراكمة للمشاريع ، يمكن لأي مطور إجراء تقييم أساسي إطاري لكل مشروع تالي. بالطبع ، هذا تقدير تقريبي للغاية ، ولكن في مرحلة ما قبل الاختبار ، يكون هذا التقدير أفضل من لا شيء. لتوضيح ذلك ، يتم ضبط أساس KSLOC وفقًا لصيغة معينة لمعاملات الصقل. لن نعطي الصيغة ، فهي بسيطة ومتاحة على الإنترنت. خلاصة القول هي أن كل مطور يمكنه تطوير معاملات هذه الصيغة على أساس إحصاءات من المشاريع السابقة ومقارنتها بالمعلمات المتعارف عليها للصيغة ، أو ... عدم مقارنة واستخدام صيغته الخاصة فقط.
يشير وجود صيغة ذات معلمات إلى أن جميع مشاريع تكامل النظام (أو جميع المشاريع الداخلية للمؤسسة) يجب ترميزها وتصنيفها وفقًا لكل هذه المعلمات. لمزيد من المشروعات الموجودة في حقيبة المطورين ، يمكن اختيار المزيد من المشاريع من نفس النوع لمشروع جديد يمكن فتحه للتقييم (تصفية المشروعات غير الأساسية) ، وكلما زادت دقة التقييم.
معرفة الوقت الذي تستغرقه في مشروع مكتمل لكل وحدة KSLOC (سطر التعليمات البرمجية) ، يمكنك تقييم الشدة المحتملة لمشروع مستقبلي. إذا كانت المعلمات تخزن البيانات على مؤهلات (الدرجات) للموظفين العاملين ، فيمكنك الحصول على تقدير تكلفة المشروع.
يمكن أن يتم تفصيل معلمات المشروع وفقًا لتقديرك وقدراتك. لمزيد من التفاصيل ، قدرت بدقة أكثر توقيت وتكلفة المشروع في المستقبل.
ما تم تعيين KSLOG في مرحلة ما قبل البيع مع وصف غير دقيق للنتيجة؟ فقط التجريبية من قاعدة بيانات مشاريع التكامل (المنفذ). في هذه الحالة ، يمكن استخدام مجموعة واحدة من معلمات المشروع. إذا كان هناك وصف دقيق للنتيجة المرجوة للمشروع (منتج البرنامج) ، فيمكن استخدام مجموعة موسعة من معلمات المشروع.
هذا هو بيت القصيد من طريقة كومكو.
الانتقال من تقييم العمل للمطورين إلى تقييم العمل للمحللين وعلماء المنهجيات
سوف يصيح القراء المهتمون وذوي الخبرة:
"حسنا اذن! مع كل إيجابيات وسلبيات طريقة COCOMO ، تم تصميمه لتقييم مشاريع البرامج. عمل المطورين والمبرمجين يمكن رقمنة في KSLOC الشرطي. ولكن ماذا عن المحللين وعلماء المنهج ، ومديري المشاريع والمديرين؟ وما علاقة 1C DSS به؟ "
هذا صحيح!
لذلك ، تتمثل المهمة في تحديد أساس مشابه لأعضاء الفريق المدرجين في القائمة والذي سيسمح لك باستخدام تقنية COCOMOII. هنا يذهب على المسرح.
الكود الزائف
من وثائق نتائج المشروع أحد أنواع نتائج جميع المشاريع المعقدة لتصميم وإنشاء وتطوير نظم المعلومات. هذه هي المهام الفنية ، وثائق المفهوم ، الأوصاف ، التعليمات ، سجلات كائنات البيانات ، قوائم المحللين ، إلخ. جدول محتويات هذه الوثائق ، نصوص المحتوى ، الجداول ، الأشكال ، المتطلبات التي تم جمعها ، القوائم هي الرمز الكاذب.
وهذا الرمز الزائف هو مقياس لنتائج عمل أعضاء "المشروع غير المبرمجين" في فريق المشروع - المحللون وعلماء المنهجيات والكتاب الفنيون وإدارة المشاريع والمهندس المعماري والمصمّمون والمشاركون المماثلون.
إذا تم تقديم المشروع وفقًا لمتطلبات GOST ، فسيتم تحديد هيكل مستندات المشروع وفقًا لهذه المعايير ، وإلا ، يتم إنشاؤه وفقًا لتقدير المقاول أو وفقًا لمتطلبات العقد مع العميل.
النقطة المهمة هي أن فريق المشروع والعميل يقرران مواكبة العصر وسيقومون بوضع نتائج المشروع حصريًا باستخدام تقنية بلا أوراق ، كيف سيتم ربط 1C DSS بهذا؟
الجواب - في الطريقة الأكثر مباشرة - DSS ومحتويات الأدلة التي تم ملؤها من قبل المشروع سيكون كائن بيانات منظم ونتائج العمل. وهو مناسب جدا لنقلها إلى العملاء. سيتم إرفاق جميع المستندات التي تم إنشاؤها أثناء المشروع بمستندات كائنات تكوين DSS.
تنقسم مستندات مشروع الإخراج المبسطة إلى مجموعات الكود الزائف التالية:
- هيكل (جدول المحتويات) من الوثيقة ؛
- اختبار الوثيقة ؛
- وثيقة جدول الصف (الجدول) ؛
- رسم (كائن رسومي).
في أبسط الحالات ، على أساس COCOMO ، بنية وثائق الإخراج كافية. يمكن أن يكون التعقيد (عدد مستويات التعشيش) وعدد خطوط جدول المحتويات بمثابة أساس لتطبيق صيغ طريقة تقدير شروط المشروع وتكلفته من خلال إحصائيات مماثلة من مشاريع سابقة وهيكل المشاركين في فرق المشروع (وليس المبرمجين). بطبيعة الحال ، فإن إدراج جميع أنواع الشفرة الزائفة في الأساس سيزيد من دقة التقدير.
وبالتالي ، فإن التناظرية KSLOC في COCOMO القياسية هنا يصبح جدول محتويات وثيقة مشروع الإخراج و / أو سطر النص من هذه الوثيقة (كل سطر من كل جدول في هذا المستند ، كل كائن رسومي). يجب ألا يتضمن الأساس عناصر التصميم وتخطيط المستند.
1 DSS والرمز الزائف
السؤال الذي يطرح نفسه هو كيفية وضع رمز زائف في 1C DSS.
يمكن القيام بذلك من خلال دليل "كائنات البيانات". يتم إنشاء مجموعة منفصلة "OUTPUT DOCUMENTS" ، ضمنها مجموعات فرعية لكل نوع من أنواع المستندات ، ثم مجموعة فرعية أخرى لكل وثيقة منفصلة ، وداخل هذه المجموعات الفرعية كعناصر في دليل جدول محتويات وثيقة المشروع.
إذا تم اتخاذ قرار بتضمين محتوى نص ، وجداول ، وكائنات رسومية لوثائق مشروع المخرجات في أساس COCOMOII ، فيجب أن يتم أيضًا جدول محتويات وثيقة المشروع في مجموعات دليل "كائنات البيانات" ، وفي داخلها يجب وضع أسماء الجداول والكائنات الرسومية وفقرات النص.
يمكن كتابة نص مستند المشروع نفسه في فقرات كحقل نص لعنصر الدليل "كائنات البيانات".
ما الذي يجب على المرء السعي لتحقيقه عند وصف هيكل مستندات مشروع الإخراج في الكتاب المرجعي "كائنات البيانات"؟
من الضروري السعي لضمان أن كل عنصر من عناصر دليل "كائنات البيانات" يمكن أن يكون له رابط لكائن بيانات تعريف واحد و / أو لكائن بيانات واحد (من مجموعات أخرى من دليل "كائنات البيانات" لا يصف الهياكل الأخرى لمستندات المخرجات ، ولكن الأنواع الأخرى التي تم إنشاؤها على مشروع البيانات ، على سبيل المثال: قوائم المحللين).
سيمكّن هذا التصميم من إنشاء مستندات مشروع الإخراج تلقائيًا ، مباشرةً من 1C DSS. سيساعد هذا في تقليل الوقت الذي تقضيه في العمل الجماعي في المشروع بشكل كبير ، خاصة في ظروف التغيير المستمر لمتطلبات العملاء ، وتعديلات نظام المعلومات ، بما في ذلك الفرق الأخرى وفناني الأداء عند الضرورة لإعادة إنشاء مستندات الإخراج مرة أخرى ، ولكن في نفس الوقت الحفاظ على تماسك الكائنات وأوصافها.
عند ربط كل عنصر أو مجموعة من عناصر "كائنات البيانات" في الدليل بالمتطلبات (تم صياغتها من قِبل العميل وأعضاء فريق المشروع ، والمفصّل بالبيانات الوصفية) ، يمكنك أخيرًا الحصول على متطلبات ارتباط من طرف إلى طرف - كائنات بيانات التعريف - مستندات مشروع الإخراج. في DSS 2.0 ، "الأفكار" تعادل "المتطلبات".
مع تراكم الخبرة في تنفيذ المشاريع في 1C DSS ، سوف تتبلور بنية الدليل التي ستكون هي نفسها في جميع المشاريع المماثلة. لذلك ، بالنسبة لمشروع جديد ، يكفي نسخه ببساطة. وللمشاريع متطابقة في نتائج الإخراج ، يمكنك نسخ النص (الجدول).
ملخص
يمكن للمتكاملين والمنظمات التي لديها قاعدة بيانات متطورة للمشاريع ، بعد تدقيق مواد المشاريع السابقة ، الحصول على تقييم موضوعي لتوقيت وتكلفة المشروعات المخططة والجارية تحت تصرفهم.
هذا من شأنه أن يسهل إلى حد كبير أ) التفاوض مع العميل ب) تقييم الأرباح المتوقعة.