ما هو الفرق بين الخلل و طلب التغيير في المنظمة لنموذج نضج القدرات المتكامل?

Question

أنا حاليا تقييم MSF for CMMI قالب العملية تحت TFS للاستخدام على فريق التطوير, و أنا أواجه مشكلة في فهم الحاجة إلى فصل الشوائب و طلب تغيير عنصر العمل الأنواع.

وأنا أفهم أنه من المفيد أن تكون قادرا على التفريق بين الأخطاء (أخطاء) و طلبات التغيير (تغيير متطلبات) عند إنشاء التقارير.

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

ما هي فوائد وجود مستقل سير العمل الحشرات ؟

أنا أيضا في حيرة من حقيقة أن المطورين يمكن أن يقدم العمل ضد الخلل أو طلب تغيير ظننت المقصود سير العمل كان عن الخلل لتوليد طلبات التغيير التي ما المطور المراجع عند إجراء تغييرات.

Answer 1

@لوقا

أنا لا أختلف معك ولكن هذا الاختلاف هو عادة شرح لماذا هناك نوعين مختلفين من العمليات المتاحة للتعامل مع نوعين من القضايا.

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

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

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

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

علة ذلك هو أن شخصا ما قال هذا كيف ونحن في طريقنا للقيام بذلك ثم شخص ما فعل ذلك بطريقة مختلفة.

تغيير الطلب هو أكثر مثل ولكن نحن بحاجة إلى النظر في هذا الشيء الآخر أيضا...همم....

هناك استثناءات بالطبع ، ولكن اسمحوا لي خذ أمثلة على حدة.

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

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

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

مرة أخرى, سوف يكون هناك بالطبع استثناءات.

في أي حال ، الأصلي فرق ذكرت هو واحد لقد وجدت أن يكون صحيحا في معظم الحالات.

Answer 2

نضع في اعتبارنا أن جزءا من عمل نوع البند تعريف TFS هو تعريف من هو "سير العمل" وهذا يعني أن الولايات عنصر العمل يمكن أن يكون الانتقال بين الدول.هذا يمكن أن يكون المضمون الدور الأمني.

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

عن "علة" ومع ذلك ، فإن أي مستخدم للتطبيق يجب أن تكون قادرة على الشروع في الخلل.

في منظمة أنا نفذت TFS في, فقط رؤساء الأقسام يمكن أن تكون مصدرا من "طلب تغيير" لكن "البق" تم إنشاؤها من "مكتب المساعدة" تذاكر (لا الآلي فقط من خلال عملية...)

Answer 3

عموما ، على الرغم من أنني لا أستطيع أن أتكلم عن CMM, طلبات تغيير والبق يتم التعامل معها و النظر بشكل مختلف لأنها تشير عادة إلى قطع مختلفة من دورة حياة التطبيق.

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

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

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

---

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

وبالتالي سير عمل مختلفة قد يكون من الضروري التعامل مع اثنين من السيناريوهات المختلفة.على سبيل المثال, قد يكون لديك طريقة مختلفة تؤكد ورفع الخلل من أجل التغيير الطلبات التي قد تتطلب المزيد من العمل لوضع عواقب التغيير.

Answer 4

الخلل هو الشيء الذي هو كسر في الشرط الذي تم بالفعل الموافقة على التنفيذ.

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

هما مختلفة جذريا تحت CMM.

Answer 5

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