مراجعة كتاب عن تطوير البرمجيات من قبل كارل ويجرز وجوي بيتي

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

الايجابيات

تم رسم كل شيء

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

من السهل العثور على المعلومات

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

للجميع في مجال تكنولوجيا المعلومات

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

شرح الشروط

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

سلبيات

الإسهاب

المؤلفين يسيئون استخدام الجمل الطويلة والمعلومات غير الضرورية. ولهذا السبب ، يصعب فهم المعنى.

"تساعدك أدوات إدارة المتطلبات في تتبع المتطلبات ، مما يجعل من الممكن تحديد العلاقات بين الأنواع المختلفة للمتطلبات ، وبين المتطلبات في الأنظمة الفرعية المختلفة ، وبين المتطلبات الفردية ومكونات النظام ذات الصلة (مثل التصميم ووحدات التعليمات البرمجية والاختبارات ووثائق المستخدم)."

ليو تولستوي ، أليس كذلك؟

"... يمكن أن توفر طرق الاتصال مزامنة فعالة في الزمان والمكان داخل الفريق."

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

"مخطط الدولة لحالة طلبات الطعام."

لا يكرر المؤلفون مرتين ، لا يكررون.

"يصف ستيفن ويثال (2007) العديد من المخططات لتوثيق البيانات بدقة (تسمى أيضًا المعلومات)."

البيانات = المعلومات. وهناك شيء لها!

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

أخطاء نحوية

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

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



كيف تحب هذه العبارة؟

"إعادة تصميم النظام من أجل معالجة أفضل لقواعد الأعمال المتقلبة التي كانت بمثابة دعم مشروع معقد."

وضع المنتج

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

تقدير

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

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

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

ما الذي يهم روسيا؟

قبل القراءة ، فكرت في شيء من هذا القبيل: "ما الذي يمكن أن يقدمه لنا أمريكي؟ لديهم كل شيء بالأرقام ، ولا توجد مشكلة ". اتضح أن المشاكل هي نفسها.

لا ثقافة احترام المتطلبات

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

لا متطلبات العمل

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

"إرفاق" للتصميم

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

لا فهم لخصائص المحلل

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

لا توجد أدوات مستخدمة

أراد أحد الرؤساء من العاملين مع المعارف التقليدية أن يعرفوهم بالقرب من النص. هذا غير واقعي. تمتلك الشركة عدة عشرات من المعارف التقليدية ، وعددهم في ازدياد. إذا انتهيت بنفسك من صياغة المعارف التقليدية قبل شهر ، فلا تزال تنسى ذلك ، لأنك حينئذٍ تزج نفسك في 2-3 جديدة. لا يتم حل المشكلة بسبب الذاكرة ، ولكن بسبب تنفيذ أنظمة إدارة المتطلبات (SUT). وهي تدعم تحديد المتطلبات وإدارتها وتتبعها وسحبها. لكن عليك أن تدفع لهم ، ويفضل أصحاب العمل العمل بالطريقة القديمة ، كما في القول:

جنديان من كتيبة البناء يحلان محل الحفار.
وتقوم إحدى القوات المحمولة جواً باستبدالها بشكل مضاعف.

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

الخلاصة

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