حلول التصميم: اللعب وفقًا لقواعدك

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



مصدر

إطار البحث

, .



.

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



عند إنشاء برامج لصالح المؤسسات الحكومية ، يرتبط النشاط الرئيسي للمحللين بحل مشكلات مثل:

• إدارة متطلبات؛
• تشكيل بيانات المهام للمبرمجين وتخطيط التنفيذ والتحكم في تنفيذ هذه المهام ؛
• إعداد وثائق المشروع.

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



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



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



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





المصدر



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



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

وثائق التصميم مقابل حلول التصميم؟

كم هو جميل على الورق ، ما

أسهل اتباع الكلمات.

كم هو سهل أن تجعلك معصوما من الخطأ.



ب. غريبينشكوف

على الرغم من حقيقة أن تعريف مفهوم "حل التصميم" ورد في GOST 34.003-90 ، في حالتي "تم اكتشاف" معنى هذا المفهوم في سياق محاولات مؤلمة وغير مثمرة للاتفاق مع ممثلي العملاء على العديد من المتطلبات المترابطة ولكن الغامضة ، عندما تجاهل العملاء ببساطة المقترح المقترح نصف تحديد الأهداف ( TMP ) ، التي تم تشكيلها بما يتفق بدقة مع RD 50-34.698-90. بعد إدراك أن القرار من جانب العميل لن يتم اتخاذه حتى بدء الاختبار ، تم إجراء المناورة التالية: تم إرسال حل التصميم الخاص بنا إلى العميل (أي حل لم يكن ملزمًا رسميًا بالموافقة عليه). 



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



كان الكوكتيل الناتج في نفس الوقت مشابهًا في الشكل لمستند تم إعداده وفقًا لمتطلبات RD 50-34.698-90 ، ولكنه في الواقع لم يتوافق مع أي من التنسيقات الواردة في GOST. في الوقت نفسه ، تم فهم ما هو مكتوب فيه من قبل ممثل عادي غير مستعد للعميل. كانت المتطلبات المحددة في هذا المستند واضحة تمامًا لكل من العميل والمقاول. تم تحديد حدود المتطلبات والنطاق المطلوب للعمل المخطط له وكيف كان ينبغي إتمام هذه الأعمال.



احتوت رسالة الغلاف على شيء مثل هذا:



"نقدم بديلاً لحل التصميم لتلبية المتطلبات المدرجة. نبلغكم ببدء العمل على تنفيذ الخيار المعروض. إذا كنت لا توافق على حل التصميم المقترح ، فيرجى إبلاغنا بذلك ".



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



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



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

 وصف الفيل ليس وفقًا لـ GOST

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



فريدريك بروكس

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





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

1. قائمة متطلبات العملاء (التي سيتم تنفيذها كجزء من حل التصميم).
2. قائمة التعاريف والاختصارات.
3. قائمة الوثائق المعيارية المنظمة للعملية الآلية.
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

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

, , , .

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



العمل في إطار تعيينات التصميم جميع عناصر واجهة المستخدم ، بالإضافة إلى الشفافية في فهم حدود التنفيذ ، يوفر أيضًا حلًا لعدد من المشكلات:

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

المصدر



أود أن أقول بضع كلمات حول مبادئ تصميم واجهات المستخدم لأنظمة التحكم الآلي. على الرغم من النمو الهائل في استخدام الأجهزة المحمولة ، لا تزال أجهزة الكمبيوتر المكتبية والمحمولة خارج المنافسة على أنظمة التحكم الآلي المستخدمة في الوكالات الحكومية (وكذلك لحل مشاكل البرمجة وإدارة النظام). حاليًا ، ظهرت مجموعة متنوعة من الأدوات لنماذج الواجهات . ومع ذلك، وشرح تفاصيل استخدام FIGMA أو Axure في مصلحة الأجهزة النقالة يفقد 10٪ من الطرق البدائية التي تسمح لك لتصميم 90٪ من واجهات المستخدم.ACS .



من واقع خبرتي ، لتقليل مشاكل تطوير البرامج بشكل كبير ، تحتاج إلى اتباع بعض القواعد البسيطة عند تصميم واجهات المستخدم.



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



لن أعطي مثالاً على واجهة IntelliJ IDEA أو PhpStorm هناومع ذلك ، سأحاول تشريح المكونات الرئيسية لواجهة المستخدم هذه إلى أجزاء مكونة ، من وجهة نظر محلل نظام تحكم آلي.



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





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



في إطار وصف أي نموذج قائمة ، يجب أن يحدد التصميم:

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

عند تصميم نماذج القائمة ، عملت القواعد التالية بشكل جيد:

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• قائمة رسائل المعلومات المحتملة ؛
• طرق لعرض محفوظات تغييرات الكائن.

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

1. في حالة الحاجة إلى إجراء تغييرات على الواجهات الحالية أثناء التطوير ، يجب ألا تعيد اختراع العجلة. هنا أظهر Paint.NET نفسه بشكل أفضل (بالمناسبة ، تم إعداد صور لهذه المقالة). ليس من المنطقي إعادة رسم النماذج مرة أخرى ، فمن الأسهل تغيير لقطة الشاشة النهائية.
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

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

السقالات والشدات

عادة الناس يفكرون كثيرا. لكن المشكلة تكمن في أنهم يفكرون في المشاكل وليس في حلول لها.



ديفيد ألين

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



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



المصدر



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



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

• تحليل المستندات - تقرير يستند إلى نتائج تحليل المستندات التنظيمية للعميل أو وثائق المشروع.
• المراجعة التحليلية - تقرير عن نتائج تحليل الحلول للمشكلة التي نشأت (كقاعدة عامة ، تحليل مقارن للتقنيات الجديدة أو اتجاهات السوق).
• مسح المعلومات - تقرير عن نتائج دراسة العمليات التجارية الحالية للعميل (تشكيل النموذج كما هو - " كما هو ").
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

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





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

خطة للمايسترو 

يجب ذكر كل شيء ببساطة قدر الإمكان ، ولكن ليس بشكل أبسط.



البرت اينشتاين

في كثير من الأحيان ، عندما يتعلق الأمر بجدولة عمل التحليل والبرمجة ، هناك الكثير من الجدل حول كيفية تقدير توقيت النتائج في هذه الحالة. ومع ذلك ، فإن التحليل أعلاه لهذا النشاط الإبداعي يسمح لنا بافتراض أنه لا يزال ممكنًا في إطار مشروع برمجي. تتمثل الخطوة الأولى نحو ذلك في تقسيم أعمال تصميم النظام إلى أجزاء يمكن فحصها بمعدل مرة واحدة على الأقل في الأسبوع. من الضروري السعي لضمان ألا تتجاوز تكاليف عمل المحلل لتشكيل حل تصميم واحد 5 أيام عمل (من حيث الحجم ، يجب أن يتكون حل التصميم هذا من 20-30 صفحة تقريبًا - وفقًا لـ GOST R ISO / IEC 15910-2002). وفقًا لذلك ، وفقًا لنفس المعايير ، يجب أن يستغرق المبرمج 3 ساعات كحد أقصى لمراجعة نفس حل التصميم. 



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



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



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



بالإضافة إلى السمات العامة الموضحة في مقال " JIRA: حدود المشروع"، لكل مشكلة من نوع" التحليل "في JIRA ، تم تحديد المجموعة التالية من السمات الإضافية (المخصصة) بشكل تجريبي.





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



1. إذا لزم الأمر ، يجب على المحلل المسؤول جدولة المهام في JIRA لإجراء استبيانات مع ممثلي العملاء (ترتبط هذه المهام بالمتطلبات ذات الصلة).



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



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



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

• انتهاك المبادئ الأساسية للتصنيف ، على سبيل المثال ، عند خلط علامات مختلفة داخل نفس المجموعة (أحمر ، أخضر ، دافئ) ؛
• بناء وثائق التقارير على أساس السمات التي لم يتم حسابها ؛
• ;
• - ;
• — - , .

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



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



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



4.  بعد الاتفاق مع العميل (يتم حفظ رسالة تؤكد هذه الحقيقة في JIRA) ، يمكن نقل مهمة إعداد حل التصميم إلى الحالة "مكتمل".

يتبع 

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



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



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



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

- " JIRA كعلاج للأرق والانهيارات العصبية " - الفكرة الرئيسية لتنظيم العمل في مشروع باستخدام JIRA ؛

- " JIRA: حدود المشروع " - الأحكام الأساسية لتوحيد المشروع والمتطلبات العامة لجميع أنواع مهام JIRA ؛

- " JIRA: إدارة المتطلبات " - السمات الرئيسية للتسجيل والتوضيح والتحكم في تنفيذ متطلبات العملاء ضمن النموذج المقترح ؛

- "حلول التصميم: اللعب وفقًا لقواعدك "- الجوانب الرئيسية لإدارة العمل التحليلي وتشكيل بيانات المشكلة للمطورين ؛

في إطار هذه الدورة ، يجري إعداد ما يلي للنشر:

- " مصفوفة كفاءات المحللين " - معايير لتقييم مستوى نضج المحللين في مشاريع البرمجيات المخصصة ؛

- " أين تختبئ المشاكل في المشروع " - معايير (مقاييس) التقييم التشغيلي للوضع الحالي لمشروع البرمجيات.



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

إذا كنت قد اكتشفت كيفية استخدام JIRA بشكل أكثر كفاءة في مشروعك البرمجي - شارك بأفكارك. فقط في وصف هذه الأفكار ، تجنب عبارة "بطريقة ما" و "بطريقة ما". أدعو الجميع للمناقشة. أنا في انتظار التعليقات / الاقتراحات / الشكوك / الرغبات في التعليقات.