مواد
- فرتیلی آئی ٹی کیوں؟
- فرتیلی طریقہ کار آبشار ماڈل کے مسائل کو کیسے حل کرتا ہے؟
- فرتیلی نے آئی ٹی انڈسٹری کو کس طرح متاثر کیا ہے؟
- کوئی کیڑے نہیں ، کوئی تناؤ نہیں - آپ کی زندگی کو تباہ کیے بغیر زندگی کو تبدیل کرنے والے سافٹ ویئر تخلیق کرنے کے لئے مرحلہ وار گائیڈ
- وجوہات بی ٹی کو فرتیلی طریقوں پر منتقل کردیا گیا
- تقاضوں کا ناقص انتظام
- ناقص سافٹ ویئر ڈیزائن
- ترقیاتی رکاوٹیں
- مذکورہ بالا مسائل کو حل کرنے کے لئے بی ٹی نے کیا کیا؟
- نتیجہ اخذ کرنا
ماخذ: ڈارکووجک / ڈریم ٹائم ڈاٹ کام
ٹیکا وے:
بہت سے لوگوں کے ل software ، کئی دہائیوں سے سافٹ ویئر ڈویلپمنٹ کا آبشار ماڈل معیاری رہا ہے ، لیکن اب اس کی جگہ زیادہ لچکدار فرتیلی طریقہ کار نے ان کی جگہ لی ہے۔
سافٹ ویئر کی ترقی کے لئے فرتیلی طریقہ کار آئی ٹی انڈسٹری کو مثبت طور پر متاثر کرسکتا ہے۔ فرتیلی طریقہ کار کو اپنانے کے نتائج کو متعدد طریقوں سے ماپا جاسکتا ہے۔ سافٹ وئیر کی تبدیلی کی درخواستوں کا تیزی سے رخ ، کم کیڑے ، ٹیم کی کارکردگی کی مقداری پیمائش اور رکاوٹیں ، ایگل کے کامیاب نفاذ کے عکاس ہیں۔ فرتیلی کے اثرات کو کامیابی کے ساتھ اندازہ کرنے کے ل an ، ایک تنظیم کو مختلف افراط زر کا موازنہ کرنے کی ضرورت ہے جو اگ چپل سے پہلے اور افادیت کے بعد کی ترقی سے متعلق تھی۔ فرتیلی کے حقیقی اثرات کا اندازہ محض محصول میں اضافہ یا طے شدہ کیڑے کی بڑھ کر نہیں ہوسکتا ہے۔ حقیقی اثرات کو سمجھنے کے ل Several کئی داخلی پیرامیٹرز پر غور کرنے کی ضرورت ہے۔ (فرتیلی ترقی کے بارے میں مزید معلومات کے ل Ag ، فرتیلی سافٹ ویئر ڈویلپمنٹ 101 دیکھیں۔)
فرتیلی آئی ٹی کیوں؟
آئی ٹی انڈسٹری سافٹ ویئر ڈویلپمنٹ کے آبشار ماڈل کی رکاوٹوں کی وجہ سے فرتیلی طرز عمل کی طرف مائل ہے۔ عام طور پر ، یہ مشاہدہ کیا گیا ہے کہ آئی ٹی کمپنیاں صارفین کی مانگ یا بازار کی صورتحال کو تبدیل کرنے یا سافٹ ویئر ڈویلپمنٹ کے آبشار ماڈل کی مدد سے اخراجات کو کم کرنے میں ناکام ہیں۔ یہاں تک کہ اگر ہم اس زبردست جھکاؤ کو چست طریق. کار کی طرف متوازن کرتے ہیں اور کچھ جوش و خروش کو صرف ہائپ سمجھتے ہیں تو بھی آبشار کے ماڈل کے خلاف بہت زیادہ تجرباتی آراء ہوں گی۔
سیدھے الفاظ میں ، آبشار ماڈل ایک سوفٹویئر ڈویلپمنٹ ماڈل ہے جہاں ایک ترتیب کے بعد ایک مرحلے کے بعد کام ہوتا ہے۔ اس ماڈل کے پانچ مراحل ہیں: تقاضے ، ڈیزائن ، عمل درآمد ، تصدیق اور بحالی۔ عام طور پر ، ایک مرحلے کی تکمیل کے بعد ، پہلے مرحلے میں تبدیلیاں کرنا مشکل ہے ، اگر ناممکن نہیں ہے۔ لہذا ، یہ مفروضہ یہ ہے کہ تقاضے کافی حد تک طے شدہ ہیں۔ فرتیلی ماڈل کے ساتھ بنیادی فرق اس قیاس میں ہے کہ ضروریات میں کوئی تبدیلی نہیں ہوگی۔ فرتیلی یہ فرض کرتا ہے کہ کاروباری حالات بدل جائیں گے اور اسی طرح تقاضے بھی بدلیں گے۔ لہذا ، سافٹ ویئر کو چھوٹے حصوں میں ایس ایس سے زیادہ فراہم کیا جاتا ہے ، جبکہ آبشار ماڈل میں ، پہلی ترسیل یا ریلیز ایک طویل عرصے کے بعد کی جاتی ہے۔ (ترقی کے بارے میں مزید معلومات کے ل see ، دیکھیں کہ اپاچی چنگاری تیزی سے استعمال کی ترقی میں کس طرح مدد کرتی ہے۔)
آبشار ماڈل کے خلاف سب سے قابل تنقید اس کا یہ خیال رہا ہے کہ ضروریات میں کوئی تبدیلی نہیں ہوگی۔ بہت مفروضہ ناقص اور غیر حقیقت پسندانہ ہے۔ مثال کے طور پر ، 2001 میں ، امریکہ میں 1،027 آئی ٹی پروجیکٹس کے بارے میں ہونے والے ایک مطالعے سے معلوم ہوا ہے کہ آئی ٹی منصوبوں کی ناکامی کی سب سے بڑی وجہ یہ گمان تھا۔
ایک اور مثال میں ، "ایگلیٹ اینڈ ایٹریٹری ڈویلپمنٹ: ایک منیجر گائیڈ" نامی کتاب کے مصنف کریگ لار مین نے اس بات کی نشاندہی کی ہے کہ امریکہ میں آبشار کے ماڈل کا استعمال کرتے ہوئے محکمہ دفاع (ڈی او ڈی) کے ذریعہ انجام دئے جانے والے متعدد منصوبوں میں کس طرح ناکام رہا ہے۔ ان کے مقاصد کو حاصل کریں۔ 1980 اور 1990 کے دہائیوں کے دوران ، ڈی او ڈی کو اپنے سافٹ ویئر ڈویلپمنٹ پروجیکٹس کے لئے آبشار کے ماڈل کو ڈوڈ ایس ٹی ڈی 2167 میں شائع کردہ معیار کے مطابق استعمال کرنے کی ضرورت تھی۔ چونکا دینے والے اعدادوشمار نے انکشاف کیا کہ ان سافٹ ویئر پروجیکٹس میں سے 75 فیصد کبھی استعمال نہیں ہوا تھا۔ اس رپورٹ کے بعد ، سافٹ ویئر انجینئرنگ کے ایک مشہور ماہر ڈاکٹر فریڈرک بروکس کے تحت ایک ٹاسک فورس شروع کی گئی تھی۔ ٹاسک فورس نے ایک ایسی رپورٹ سامنے آئی جس میں تبصرہ کیا گیا تھا کہ "ڈوڈ ایس ٹی ڈی 2167 کو بھی اسی طرح جدید ترین پریکٹس کی عکاسی کرنے کے لئے ایک بنیادی بنیادوں پر نظر ثانی کی ضرورت ہے۔ ارتقائی ترقی تکنیکی لحاظ سے بہترین ہے ، اس سے وقت اور رقم کی بچت ہوتی ہے۔
آبشار ماڈل کے مندرجہ ذیل چار مفروضے حقیقی دنیا کے منظرناموں میں ناکام ہوگئے تھے۔
- دی گئی ضروریات کو معقول حد تک بہتر طریقے سے بیان کیا گیا ہے اور اسی طرح ، نمایاں طور پر تبدیل نہیں ہوں گے۔
- یہاں تک کہ اگر ترقیاتی مرحلے کے دوران تقاضے بدل جاتے ہیں تو ، وہ اتنے چھوٹے ہوں گے کہ وہ ترقی کے چکر میں رہ سکے۔
- سسٹم کا انضمام ، جو سافٹ ویئر کی فراہمی کے بعد ہوتا ہے ، منصوبے کے مطابق ہوگا۔
- سافٹ ویئر جدت طرازی اور جدت طرازی کے لئے درکار کوشش ایک منصوبہ بند اور پیش قیاسی شیڈول کے مطابق ہوگی۔
فرتیلی طریقہ کار آبشار ماڈل کے مسائل کو کیسے حل کرتا ہے؟
فرتیلی طریقہ کار آبشار ماڈل سے بنیادی طور پر مختلف ہے اور یہ اس کے مفروضوں سے واضح ہے:
- کوئی بھی ، یہاں تک کہ صارف بھی نہیں ، پوری طرح سے ضروریات کو جان سکتا ہے اور نہ ہی سمجھ سکتا ہے۔ اس کی کوئی گارنٹی نہیں ہے کہ ضروریات تبدیل نہیں ہوں گی۔
- ضرورت میں تبدیلیاں چھوٹی اور قابل انتظام نہیں ہوسکتی ہیں۔ در حقیقت ، وہ مختلف سائز میں آئیں گے اور آتے رہیں گے۔ لہذا ، سافٹ ویر کو تھوڑی سی انکریمنٹ میں پہنچایا جائے گا تاکہ ان تبدیلیوں پر نظر رکھیں۔
فرتیلی نے آئی ٹی انڈسٹری کو کس طرح متاثر کیا ہے؟
فرتیلی کو بہت ساری جگہوں پر اپنایا جارہا ہے ، جبکہ بہت سی کمپنیاں ایگلی کو اپنانے کے منصوبے بنا رہی ہیں۔ اگرچہ فرتیلی نے یقینی طور پر آئی ٹی انڈسٹری میں بنیادی تبدیلیاں کیں ، حقائق اور اعداد و شمار حاصل کرنا ابھی تھوڑا مشکل ہے۔ لیکن ایگلیٹ کے اثرات کو ذیل میں دیئے گئے برٹش ٹیلی کام (بی ٹی) کے کیس اسٹڈی سے سمجھا جاسکتا ہے۔
کوئی کیڑے نہیں ، کوئی تناؤ نہیں - آپ کی زندگی کو تباہ کیے بغیر زندگی کو تبدیل کرنے والے سافٹ ویئر تخلیق کرنے کے لئے مرحلہ وار گائیڈ
جب آپ سافٹ ویئر کے معیار کی پرواہ نہیں کرتے ہیں تو آپ اپنی پروگرامنگ کی مہارت کو بہتر نہیں کرسکتے ہیں۔
وجوہات بی ٹی کو فرتیلی طریقوں پر منتقل کردیا گیا
بی ٹی نے 2004 میں اپنے سافٹ ویر ڈویلپمنٹ طریقوں میں بہت ساری پریشانیوں کا سامنا کرنا شروع کیا۔ بی ٹی نے بہت سارے سافٹ ویر پروجیکٹس تیار کیے ، دونوں ہی آسان اور پیچیدہ۔ بہت سارے سوفٹویئر پروجیکٹ متفقہ ٹائم فریم میں معیار کی پیداوار تیار کرنے سے قاصر تھے۔ بی ٹی نے پایا کہ پریشانیوں کی وجہ ان کی جڑیں آبشار ماڈل پر ہیں۔ لہذا ، آبشار ماڈل کو تقویت دینے میں مدد نہیں مل رہی تھی۔ مسائل کی بنیادی وجوہات ذیل میں دی گئی ہیں۔
تقاضوں کا ناقص انتظام
- بہت ساری ضروریات کو ایک محدود وقت میں پورا کرنے کے لئے دی گئی تھی۔
- بہت سے تقاضے کاروباری ضروریات سے غیر متعلق تھے۔
- تقریبا all ، اگر نہیں تو تمام تقاضوں کو اعلی ترجیح کا درجہ نہیں دیا گیا تھا۔
- موجودہ کاروباری ضروریات کو جن تقاضوں کی نمائندگی کرتا ہے ان میں مستقبل کے منظرناموں پر کوئی نگاہ نہیں ہوتی ہے۔ اس سے مستقبل میں سافٹ ویئر کی تبدیلیوں کا امکان باقی رہ گیا ہے۔
ناقص سافٹ ویئر ڈیزائن
- بڑی تعداد میں تقاضوں کے پیش نظر ، ڈیزائنرز نے یہ معلوم کرنے کی کوشش میں بہت زیادہ وقت صرف کیا کہ ضروریات کا کیا مطلب ہے۔ اصل ڈیزائن کے لئے بہت کم وقت باقی تھا۔
- تجزیہ کار ضرورت کے مطابق غیر تحریری اور ناقابل تسخیر علم لے کر دوسرے کاموں میں منتقل ہوگئے۔
- مذکورہ دو عوامل کا نتیجہ ناقص ڈیزائن کا تھا۔ ڈیزائنرز کو ابھی بھی اصل ٹائم لائن کے مطابق فراہمی کرنا تھی۔
ترقیاتی رکاوٹیں
ناقص سافٹ ویئر ڈیزائن کی وجہ سے کوڈنگ جلد بازی اور ناقص معیار کی تھی۔ ڈویلپرز کو یہ احساس ہوگا کہ سافٹ ویئر کے خراب ڈیزائن کے نتیجے میں خراب کوڈ پیدا ہوگا ، لیکن اس کے باوجود متفقہ ٹائم لائن کے ذریعہ فراہمی کرنا پڑی۔ انضمام کے دوران بہت سے کیڑے کی اطلاع دی جائے گی کیونکہ یونٹ ٹیسٹ اور رجعت ٹیسٹ نہیں چلائے گئے تھے۔
جب تک سافٹ ویئر کا تعی .ن ہوتا ہے ، گاہک نوٹ کرتا ہے کہ ضروریات پہلے ہی تبدیل ہوچکی ہیں اور اسی طرح کاروبار کا منظر نامہ بھی بدل گیا ہے۔ سافٹ ویئر میں بھی بہت ساری پریشانی ہے۔ مؤثر طریقے سے ، سافٹ ویئر ڈویلپمنٹ کی پوری کوشش اب ضائع سمجھی جاتی ہے۔
مذکورہ بالا مسائل کو حل کرنے کے لئے بی ٹی نے کیا کیا؟
بی ٹی نے محسوس کیا کہ آبشار کے ماڈل کو تقویت دینا پریشانیوں کا جواب نہیں ہے۔ اسے ایک نئے انداز کی ضرورت ہے۔ لہذا ، اس نے فرتیلی نقطہ نظر کو نافذ کرنے کا فیصلہ کیا ہے۔ نئے نقطہ نظر کے تحت ، مندرجہ ذیل چیزوں کا فیصلہ کیا گیا:
- 12 ماہ کے ترقیاتی دور کی بجائے ، بی ٹی اب 90 دن کے چکر میں سافٹ ویئر کے قابل عمل ٹکڑے فراہم کرے گا۔ اس خیال میں ایک یا دو کاروباری مسائل پر توجہ مرکوز کرنا تھا اور 90 دنوں میں سافٹ ویئر حل فراہم کرنے کا ہدف تھا۔ اس سائیکل کے آغاز کو مختلف اسٹیک ہولڈرز کے مابین شدید بحث و مباحثہ کیا گیا تاکہ ضروریات کی واضح شناخت ، تجزیہ اور ترجیح دی جاسکے۔
- ہدف واضح ، ٹھوس کاروباری اقدار کی فراہمی تھا۔ داخلی صارف پر واضح ضروریات فراہم کرنے کا دباؤ تھا۔ لہذا ، مبہم اہداف کے بجائے ، صارف کی کہانیاں واضح قبولیت کے معیار کے ساتھ دی گئیں۔
- جو سافٹ ویئر فراہم کیا جائے گا اس کی مکمل جانچ اور دستاویز کی جائے گی۔ یہ سافٹ ویئر بار بار انضمام کے امتحانات سے گزرتا ہے تاکہ پہلے سے ہی مسائل کی نشاندہی کی جاسکے۔
فرتیلی نقطہ نظر کے ساتھ ، بی ٹی زیادہ آسانی سے تقاضوں یا کاروباری حالات کو تبدیل کرنے کے مطابق ڈھال سکتا ہے۔ کوڈ کے معیار میں بہتری اور آخری لمحے کے بنیادی کیڑوں کو حل کیا گیا۔
نتیجہ اخذ کرنا
فرتیلی ، اپنے سارے فوائد اور اس کے آس پاس کے ہائپ کے لئے ، اب بھی اس مرحلے پر ہے جہاں اس کے امکانات کا پوری طرح سے ادراک نہیں ہوتا ہے۔ اس کی وجہ یہ ہے کہ بہت ساری تنظیمیں اپنے اصلی اصولوں میں ترمیم کرنے کی حد تک اس نقطہ نظر کو اپنی مرضی کے مطابق بنارہی ہیں۔ نتیجے کے طور پر ، آبشار ماڈل کچھ معاملات میں واپسی کر رہا ہے۔ اگرچہ تخصیص جاری رہے گی ، لیکن یہ ضروری ہے کہ ایگلس کے بنیادی اصولوں کو برقرار رکھا جائے۔ بہت سی تنظیمیں مکمل طور پر فرتیلی ہونے کا دعوی کرتی ہیں ، لیکن واقعی فرتیلی کمپنی بننے کے لئے ان کے پاس ابھی بھی کچھ راستہ باقی ہے۔