في الآونة الأخيرة ، اشتكى صديق لي من هيمنة اللغة الإنجليزية العامية في بعض المجتمعات المهنية. أجبته بأنه سيء لكنه قسري. تمامًا مثل هذا ، تتم عملية الاقتراض الطبيعي ، حيث يتم تكييف ما هو ضروري ويتم التخلص من ما هو غير ضروري. وفي اللغة الإنجليزية نفسها ، هناك عدد من اللاتينيات أكثر بكثير من الأنجليكانية الروسية. بعد كل شيء ، بمجرد التواصل مع أولئك الذين كانوا منخرطين في العلوم حصريًا باللغة اللاتينية.
في اللغة الروسية ، لا تزال هناك مساحة صغيرة حيث يلزم إدخالها إلى الحقائق الحديثة. ينطبق هذا على الممارسات الغربية في مجال إدارة الأفراد والفرق. لقد درسهم العلم السوفييتي بشكل سيئ ، بينما في التسعينات بدأ تقديمهم المتسارع من قبل الأشخاص الذين اعتبروهم مؤخرًا غير صحيحين أيديولوجياً. لذلك كان الأمر مع الاقتصاد وفي مجالات أكثر تحديدًا ، مثل تلك المتعلقة بإنتاج البرمجيات.
لقد عرفنا دائمًا كيفية كتابة رمز برنامج ممتاز. لكن أعمال البرمجيات أوسع من البرمجة المستأجرة البسيطة - إنها تجارة المعرفة. وإذا كان الأمر كذلك ، فإن الإنتاج وتنظيمه مطلوبان. هنا ، تلعب أنظمة إدارة جمع المتطلبات دورًا رئيسيًا ، حيث يجب بناء عملية الإنتاج على أساس الخبرة الغربية.
علاوة على ذلك ، في المقالة ، يتم تحليل أخطاء الاقتراض النموذجية باستخدام أمثلة من ترجمة كتاب Karl I. Wigers "تطوير متطلبات البرامج". في النهاية ، يتم تلخيص المواد التي تمت مناقشتها باستخدام نموذج V لدورة حياة متطلبات التصميم للبرامج.
مما لا شك فيه ، أن كتابًا غريبًا من تأليف Karl I. Wigers "تطوير متطلبات البرامج" (يشار إليه فيما بعد بـ RTkPO) أصبح معيارًا معينًا في مجتمع المعلومات الروسي. لكن استخدام أحكام هذا الكتاب (المستعارة ، الأصلية ، المترجمة) خارج مفهوم المؤلف تثير أسئلة أود أن أفهمها.
هذا توضيح لتطور المتطلبات مع تقدم المشروع من الأعلى إلى الأسفل ، من خلال ثلاث وثائق: "
مستند على صورة وحدود المشروع " ، "
وثيقة حول حالات الاستخدام " ، "
مواصفات متطلبات البرامج ". في الطبعة الثالثة ، يتم عرض أول وثيقتين كـ "
وثيقة المفهوم والحدود " و "
وثيقة متطلبات المستخدم "
لإنشاء المستند الصحيح ، يجب عليك أولاً فهم جوهره. يبدو أن المفتاح هو الكشف عن "
صورة وحدود المشروع " الغامضة: حلها ، ويمكنك استخدام الممارسة الجاهزة دون أي قيود ومع فائدة كبيرة. للأسف ، هذا يعمل فقط مع التقنيات البسيطة التي تم شراؤها من أطراف ثالثة. ترتبط جوانب
إدارة الفريق مباشرة بخصائص الثقافة الأجنبية ، وكل شيء ليس سهلاً هناك. الاختلافات الثقافية هي الجزء المرئي من جبل الجليد للنظام بأكمله من الصور النمطية العرقية
اللاواعية للسلوك. لكننا لا نتحكم في عالم اللاوعي على الإطلاق ، أو أننا نتحكم فيه جزئيًا فقط.
ومع ذلك ، ليس كل شيء ميؤوس منه. نحن بحاجة إلى إيجاد ارتباطات لمصطلحاتهم مع ممارستنا. سنحلل "
الوثيقة على صورة وحدود المشروع ". حدود المشروع هي
نطاق المشروع . يجب ترجمة ذلك على أنه "
عبء العمل ". ليس في القاموس؟ للأسف. يمكنك إلقاء نظرة على دليل اللغة الإنجليزية:
نطاق المشروع - جزء من تخطيط المشروع ، بما في ذلك عملية تحديد الأهداف المحددة للمشروع والنتائج والمهام والتكاليف والتوقيت ثم توثيقها . هناك إجراء محدد ، فلماذا لا نطلق عليه "
حدود المشروع "؟ في هذه الحالة ، ستنشأ مشاكل مع تكامل تجربتنا الماضية: بعد كل شيء ، كنا نخطط ، وبشكل خاص ، تحديد نطاق العمل من قبل.
عندما تفشل ترجمة القاموس ، تحتاج إلى البحث عن نموذج مفاهيمي بسيط يوضح استخدام المصطلح المثير للجدل في مجال موضوع ذي صلة. يسمح لنا النقل الإضافي لمثل هذا النموذج البسيط من الكشف إلى التربة الأصلية بالعثور على تطابقات اللغة. نموذج القيود الثلاثية هو مقدمة لإدارة المشروع.
يكشف هذا النموذج عن العلاقة بين مصطلحات "
وقت التنفيذ " و "
التكلفة " و "
مقدار العمل " (الوقت والتكلفة والنطاق) ، والتي يتم وضعها في شكل مثلث متساوي الأضلاع ، مما يعني أن تغيير جانب واحد من هذا المثلث يؤدي إلى تغيير في الكل.
أحيانًا لا تتم ترجمة
Project Vision على أنها "
صورة مشروع " ، بل "
كمفهوم مشروع " ، ولكن هذا لا يضيف وضوحًا. يتم تعريف
بيان رؤية المشروع في الكتيب بأنه "
نظرة مثالية لنتائج الأعمال المرغوبة التي سيتم الحصول عليها عند الانتهاء بنجاح من المشروع ." عادة ما نستخدم مصطلح "
أهداف المشروع " ونصوغ هذه المهام بنصيب من التشاؤم المحلي. إذا أطلقنا عليه "
صورة المشروع " ، فمن غير المرجح أن يساعد ذلك على إظهار التفاؤل الغربي على أرضه. في المجموع ، يمكن تسمية الوثيقة الأولى "
أهداف المشروع ونطاق العمل ". ولا شيء غامض.
ويعتقد أنه لا ينبغي ترجمة هذه المصطلحات ، ولكن استخدام اللغة الإنجليزية في المشروع. يعمل هذا جزئيًا فقط ، مما يحد بشكل كبير من دائرة الأشخاص ذوي الخبرة في الأمور. مهارات اللغة الأساسية ليست كافية حيث تتعلق القضايا التكنولوجية بالاختلافات العرقية الثقافية.
في ما يلي مثال نموذجي من RTkPO: "
يجب ذكر المتطلبات بالتسلسل ، على سبيل المثال ،" سيكون النظام ... "أو" سيكون المستخدم ... "، ثم الفعل النشط ، ثم النتيجة المرصودة ... يمكنك استخدام" ينبغي "كمرادف لـ" سوف "، ولكن تجنب الكلمات "ينبغي" و "ربما" و "يمكن" وكلمات مماثلة ، والتي ليس من الواضح منها ما إذا كان العمل ضروريًا .
قد تعتقد أن هذا دليل جاهز للعمل. في الواقع ، هذه الترجمة لا تساعد على اكتشافها ، لكنها تربك كل شيء أكثر. علاوة على ذلك ، فإن الأصل الإنجليزي ليس الحقيقة المطلقة ، ولكنه تعبير عن نظرة معينة حول طريقة اللغة الإنجليزية. تم تضمين العرض في معيار RFC2119 ** ، الذي يوضح قواعد استخدام الكلمات الرئيسية الإنجليزية في مجال إدارة المتطلبات (على
سبيل المثال ، يجب ، يجب ، يجب ). على سبيل المثال ، في هذا المعيار ،
يجب أن تعني "
أن التعريف هو مطلب مطلق للمواصفات ". ومع ذلك ، التقى المؤلف قوالب المستندات مع حظر مباشر على استخدام (
يجب شرح هذا الموقف على الإنترنت ***).
المستوى التالي من التفاصيل للمتطلبات هو "
وثيقة حالة الاستخدام ". في RTkPO ، يشار إلى أنه يحدد حالات الاستخدام والسيناريوهات وجداول
الاستجابة للأحداث . إن ترجمة "
حالات الاستخدام " على أنها "
حالات استخدام " تبسط وجهة نظر الأشياء بشكل غير ضروري (وبالتالي ، في الواقع ، أصبحت الأنجليكانية في
حالات الاستخدام أكثر رسوخًا). يجب أن تتمتع البرامج الحديثة بالحماية من القرصنة والحماية من أحمق ، ولكن اعتبر هذا خيارًا للاستخدام - العنف ضد اللغة الروسية. للترجمة ، يتم اقتراح "سيناريوهات التفاعل".
في الواقع ، نموذج
الاستجابة للحدث معروف لنا. في المدرسة الثانوية ، يتم دراستها على أنها "
تأثير - تقلب -> استجابة ". تحت نفس التأثيرات ، قد تختلف استجابة النظام بسبب التقلبات العشوائية. في برامج المستخدم ، عادة ما تكون هذه حالات خطأ مختلفة. بالإضافة إلى ذلك ، على مستوى المفهوم ، يجب تمييز الآثار البيئية عن تأثيرات المستخدم. اسم مناسب إلى حد ما لهذا المستوى من المتطلبات هو "
متطلبات النظام " أو "
متطلبات منتج البرنامج " بالفعل ، على الرغم من أن المصطلحات لم يتم تأسيسها وواجهت خيارات مختلفة جدًا (على سبيل المثال ، في الإصدار الأخير ، يتم استخدام اسم "
مستند متطلبات المستخدم " ، والذي يتم تلقائيًا يستثني الأنظمة المدمجة من الاعتبار).
جوهر تطوير متطلبات هذا المستوى هو إنشاء نموذج تخميني مفصل للبرمجيات التي تعمل في عالم خارجي مثالي. لذلك ، نقطة مهمة هي وضع الحدود والافتراضات. "
يمكن أن يكون لون السيارة أي لون ، شريطة أن يكون أسود " - لذلك أعاد هنري فورد تصميم متطلبات العمل الخاصة بلون السيارة إلى افتراض. ومع ذلك ، في وقت آخر ، من أجل تلبية متطلبات العمل لنظافة السيارة ، تبين أنه من الضروري صنع زجاج مبسط غير مستو. قال مهندسو فورد إنه مستحيل من الناحية التقنية. وجد فورد المخترعين الشباب على الجانب.
ويمثل المستوى الأدنى "
مواصفات متطلبات البرامج " ، والتي تتضمن "
القيود " و "
الواجهة الخارجية " و "
سمات الجودة " وفي الواقع "
المتطلبات الوظيفية ". هذه هي الوثيقة الأخيرة في الشكل ، للأسف ، لم يتم تناول أسئلة الاختبار اللاحق. لذلك ، من أجل صياغة التعريف ، يضطر RTkPO إلى استخدام مفهوم متطلبات الأعمال: "
تحدد المتطلبات الوظيفية وظائف البرامج التي يجب على المطورين إنشاؤها
حتى يتمكن المستخدمون من إكمال مهامهم في إطار متطلبات الأعمال "
من ناحية الاختبار ، يكون التعريف أسهل في البناء: "
المتطلبات الوظيفية هي متطلبات يتم اختبارها ". يجب أن يُفهم هذا على أنه القدرة على اختبار كل متطلب وظيفي باختبار بالمعنى الكلاسيكي (مع الحكم - تمرير أو فشل). العكس ، بالمعنى الدقيق للكلمة ، ليس صحيحًا: قد توجد بعض الاختبارات بمفردها. لكن وجود مثل هذه الاختبارات هو مؤشر على السهو في العمل على المتطلبات. بعد كل شيء ، يتحقق الاختبار من أي قسم من التعليمات البرمجية لم يظهر من تلقاء نفسه ، ولكن نتيجة لتنفيذ متطلبات وظيفية معينة.
تحاول عمليات تطوير البرمجيات الناضجة الحديثة إدخال مكون القياس في المراحل الأولى من تصنيع منتجات البرمجيات. دون الخوض في التفاصيل - معظم هذه مقاييس التغطية. أحد مؤشرات جودة المنتج المستقبلي هو النسبة المئوية للتغطية مع اختبارات المتطلبات الوظيفية ، والتي يتم حسابها باستخدام جدول (مصفوفة) للتغطية (مصفوفة التتبع). من الممكن تضمين متطلب غير وظيفي في المصفوفة ، ولكن في العمل المستقبلي سيتم وضع علامة عليه على أنه غير قابل للاختبار ، والأهم من ذلك ، سيختبره المختبرون على أنه غير مفيد. يبدو أن "
تحديد متطلبات البرامج " الكاملة بقائمة من المتطلبات غير الوظيفية مفيد جدًا للمبرمجين. وربما يكون الأمر كذلك إذا نظروا إلى هناك بعد التجميع على الأقل من وقت لآخر.
يمكن كتابة الغالبية العظمى من المتطلبات غير الوظيفية بطريقة وظيفية. لإعادة الصياغة ، يمكن معالجة أي متطلبات غير وظيفية لنظام أو منتج برمجي تقريبًا في واحد أو أكثر من المتطلبات الوظيفية.
تقع سمات الجودة في RTkPO جزئيًا في المتطلبات الوظيفية ، وهذا صحيح تمامًا. ومع ذلك ، يتم تحديد القيود والواجهة الخارجية لـ RTkPO على النحو التالي: "
المتطلبات الأخرى غير الوظيفية تصف التفاعلات الخارجية بين النظام والعالم الخارجي ، وقيود التصميم والتنفيذ. "القيود (القيود) تتعلق باختيار إمكانية تطوير مظهر وهيكل المنتج ." دائمًا ما يكون للأنظمة الفرعية للاتصالات مع العالم الخارجي واجهة تعمل وتخضع للاختبار.
هل يمكن أن تكون القيود متطلبات وظيفية؟ نعم بالتأكيد ، إذا كتبتها في شكل معكوس كفرص. على سبيل المثال ، يجب أن يكون المنتج أسرع من المنتج المنافس (وإلا فلن تكون هناك حاجة - تقييد شديد للغاية). بادئ ذي بدء ، نحن نتحدث عن حداثة القرارات المتخذة والموثقة ، بما في ذلك في شكل متطلبات. ولكن من الواضح أن النظام يجب أن يكون لديه وحدة لقياس المعلمات المكتشفة لهذه السرعة ، وفي مرحلة مبكرة.
لذا ، فإن "
المواصفات الوظيفية " هو اسم معروف لمواصفات المستوى الأدنى في شكل مستند منسق أو كقاعدة بيانات تحت سيطرة البرامج المتخصصة.
ماذا سيحدث للمتطلبات التالية؟ بالإضافة إلى المطورين (المبرمجين) ، سيعمل مهندسو الاختبار ومهندسو ضمان الجودة (QA) مع المتطلبات. يمكن ترجمة "الاختبار" على أنه "تحقق" ، ولكن يبدو أن "الاختبار" قد تم. تتطلب ترجمة ضمان الجودة مرة أخرى نموذجًا للإفصاح - هنا ، تستند إليه المبادئ. أولاً ، "
صالح للغرض " (يجب أن يكون المنتج مناسبًا للغرض المقصود) ، وثانيًا ، "
المرة الأولى الصحيحة " ("المرة الأولى" - يجب التخلص من الأخطاء) وثالثًا ، استقلالية المشروع. هذا هو "
القبول " ، تكمن المبادئ في القبول العسكري المعروف وقبول الدولة الأسطوري.
ستشكل المواصفات المطلوبة الأساس لوثائق التصميم الإضافية. كحد أدنى ، سيتم استخدام المتطلبات في تطوير
وثائق المستخدم . من المقبول عمومًا أن الاختبار يبدأ
بخطة اختبار وينتهي
بتقرير اختبار - وثائق تتعلق مباشرة بالمواصفات. يمكن للمرء أن ينظر إلى الشكل في RTkPO بشكل مختلف - كنموذج معمم لعملية تطوير البرمجيات (أو نموذج دورة حياة البرنامج). في هذا النموذج ، تكون المستندات النهائية هي نقاط الدخول / الخروج بين مراحل العملية.
بالترتيب الزمني ، سيتم تقديم المستندات على النحو التالي: متطلبات العمل (كجزء من نطاق المشروع) ، متطلبات النظام (PO) ، المتطلبات الوظيفية ، خطة الاختبار ، تقرير الاختبار ، وثائق المستخدم. الخط بين المستندين هو مرحلة العملية. غالبًا ما يتم رسم النماذج على شكل دورات متكررة أو لوالب ، ومع ذلك ، فإن المحور الزمني البسيط أكثر وضوحًا. ثم تتم الإشارة إلى المرحلة الأولى والأخيرة من العملية ليس من خلال مقطع ، ولكن بواسطة شعاع. في العروض التقديمية الحديثة ، ينحني المحور الزمني في منتصف مرحلة الترميز في شكل الحرف "
V " ، ويحصل على ما يسمى
بالنموذج V.
تُظهر الخطوط المتقطعة اتصالات تجاوزت المحور الزمني ، مما يدل على القدرة على بدء بعض العمل مقدمًا. على سبيل المثال ، مع متطلبات العمل المصاغة ، يمكنك بالفعل أن تقول شيئًا عن وثائق المستخدم للمنتج ، وستعطي المتطلبات المشكلة للنظام نموذجًا للبرامج المستقبلية ، والتي يمكن تقييم جودتها بالفعل.
لكن الوظيفة الرئيسية لهذه الخطوط هي إظهار قابلية التوسع (التبسيط) للنموذج V.
يعد دعم جميع المراحل والمستندات دائمًا متعة باهظة الثمن ، وهو سبب شائع جدًا للخسارة أمام المزيد من المنافسين المتنقلين . على سبيل المثال ، يعمل فرد مثل هذا: متطلبات العمل -> التطوير (التشفير) -> وثائق المستخدم. هذا هو الخط المكسور العلوي للقطع. كقاعدة ، تتخطى شركات الاستعانة بمصادر خارجية المراحل الدنيا دون إنفاق الأموال على المواصفات الوظيفية وهي محدودة بنوع أو آخر من متطلبات النظام (على سبيل المثال ،
سيناريوهات التفاعل ). بالنسبة للمنتجات من نفس النوع ، عادة ما يكون هناك معيار مؤسسي ، ومن مرحلة التشفير يتم إصدار تقرير معين عن الاختبار الداخلي للمطورين من أجل بدء مرحلة ضمان الجودة / القبول.
يساعد النموذج V الأساسي في توضيح مجالات المسؤولية. على سبيل المثال ، يلعب الموظف دور مهندس القبول (QA) أو مهندس الاختبار ، اعتمادًا على المرحلة التي يعمل فيها. لا يهم إذا تم تكليفه بمشروع أو قسم معين. وينطبق الشيء نفسه على المحلل ، المصمم ، المطور - إن القدرة على أداء كل هذه الأدوار من قبل شخص واحد لا تدحض نموذج V. بالنسبة لمهندس القبول والمحلل ، فإن الأساس هو "متطلبات النظام" ، فهم يعملون مع البرنامج المطور كصندوق أسود. بالنسبة للمشاركين في المراحل ، فإن التصميم والتطوير والاختبار هو صندوق أبيض ، وإن كان إلى حد مختلف.
في الختام ، تجدر الإشارة إلى أن نموذج V لا يزال عرضًا (في هذه الحالة ، يوضح تطور تصميم المتطلبات). هذا ليس دليلاً مباشرًا للعمل ؛ عمليات تطوير البرمجيات الحقيقية أكثر تعقيدًا. ولكن من الصعب الاستهانة بقدرتها الكاشفة.
* كارل آي ويجرز "تطوير متطلبات البرامج".
** الكلمات الرئيسية للاستخدام في طلبات RFC للإشارة إلى مستوى المتطلبات (https://tools.ietf.org/html/rfc2119)
*** يجب - لا تستخدم يجب لأنه لا أحد قد حدد كيف يجب أن يكون مختلفًا عما يجب. أيضا ، يجب أن يكون قد عقد في المحكمة ، يجب أن لا. صحيح ، هل يجب أن يبدو أقوى ، أليس كذلك؟ أعني ، إذا أخبرك رئيسك أنك "يجب" أن تفعل شيئًا ، فستفعل ذلك. ولكن عند كتابة المتطلبات ، حافظ على بساطة الأمور واستخدمها فقط (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)