مقاله رایگان درباره نرم افزار، ارزش افزوده

کار با توسعه (توليد کد) و بازرسي دنبال مي گردد. از نيمه دوم دهه نود برخي از صاحبنظران نرم افزار به اين نتيجه رسيدند که شروع فرايند توليد نرم افزار با فازهاي سنگين و دقيق مطالعه نيازمندي ها و طراحي کامل، بسيار وقت گير و در مواقعي غير قابل انجام است[7]. در واقع رشد سريع صنعت و لزوم تغيير نيازمنديها مجالي براي استفاده از روشهاي سنتي نميداد. بسياري از مشتريان در ابتداي کار نمي‌توانستند نيازمندي هاي خود را به طور دقيق و کامل بيان کنند، در عين حال انتظارات آنها از محصول نهايي هم فراتر از بيان اوليه آنها بود. در نهايت برخي از متخصصين به طور مجزا به ايجاد تغييراتي در فرايندهاي توليد نرم افزار خود نمودند که به نحوي بتوانند پاسخگوي مشکل فوق باشند. در واقع با ايجاد فعاليتهاي جديد در فرايند توسعه نرم افزار اقدام به ايجاد ارزشهايي در فرايند توسعه نموده اند که تا حدي مي توانست مسائل مربوط به تغيير سريع صنعت و نياز آن را جوابگو باشد. بررسي اجمالي اين روشها نشان مي‌دهد که در خيلي از موارد اين روشها فعاليت کاملاً جديدي را نشان نمي دهند]8[، آنچه در اين روشها بيشتر به چشم ميخورد توجه به ارزشهايي است که نسبت به روشهاي سنتي پررنگ تر شده اند. بهبود فرايند نرم افزار فرايندي تکاملي است به نحوي که فرايندهاي جديدتر بر پايه توفيق ها و يا شکستهاي فرايندهاي پيشين ساخته مي‌شوند و شايد حقيقت امر اين باشد که براي شناخت روشهاي چابک لازم باشد فرايندهاي پيش از اين روشها نيز بررسي شوند.
روش (مدل) آبشاري 1 اولين فرايند توسعه نرم افزار بوده]9[که با شناخت و تحليل کامل نيازمنديهاي کاربر شروع مي‌شود. براي اين امر تحليل گران لازم است تا چندين ماه به طور کامل همه نيازمنديهاي کاربر را بررسي کرده و مستندات دقيقي در خصوص آنها تهيه و به تأئيد کاربر برسانند. سپس برنامه نويسان با بررسي کامل اين مستندات اقدام به طراحي دقيق جزئيات کاربردي نرم افزار نموده و پس از آن مرحله توليد (کدنويسي) سيستم انجام ميگيرد و در نهايت پس از تست کامل سيستم، محصول به بازار عرضه مي‌گردد [10].
اين فرايند در حالت تئوري خوب و مناسب به نظر ميرسد، اما در عمل برخلاف آنچه به نظر ميرسد، در موارد زيادي درست کار نمي‌کند. در درجه اول کاربران پس از مدتي نظراتشان عوض مي شود و گاهاً پس از ماهها و يا حتي سالها عليرغم تهيه مستندات کامل از نيازمنديهاي کاربران، آنها هنوز مطمئن نيستند که دقيقاً چه چيزي نياز دارند. در درجه دوم پس از مدتي نيازمنديهاي گفته شده، در ذهن توليدکنندگان نقش مي‌بندد و تغيير اين موارد دشوارتر از قبل خواهد شد. روشهاي سنتي وقتي نرخ تغييرات در نيازمنديها پايين باشند، هنوز هم مناسب هستند]11[، چرا که کاربران، توليدکنندگان، معماران و مديران سيستم لازم است که همه تغييرات (هرچند کوچک) را در نظر بگيرند و لحاظ نمايند. در مدل آبشاري فرض بر اين است که نيازمنديها تغيير نمي يابند و تا پايان پروژه ثابت هستند و براي اطمينان از اين امر، در مواردي تائيد رسمي کاربر را نيز دريافت مي‌کنند. اما در نهايت ممکن است، محصول کاربردي مناسبي ايجاد نگردد. تکنيکهاي توسعه نرم افزار تدريجي (تکاملي) و تکراري براي حل نقص فوق، بر پايه تقسيم چرخه توليد نرم افزار آبشاري به چندين قسمت، بنا نهاده شده اند [12]. روش توسعه تدريجي تأکيد بر کاهش زمان توسعه دارد و براي حصول به اين امر، اقدام به شکست پروژه به چندين بخش مي نمايد که اين بخشها مي توانند در زمان توسعه همپوشاني داشته باشند، اگرچه اين تکامل باز هم بر اساس مدل آبشاري انجام ميگيرد. در واقع تنها دستاورد اين روش (ها) کاهش زمان توسعه است و کماکان مسائل مربوط به نيازمنديها و مشکل تغيير در آنها وجود دارد.
در زماني که روشهاي توسعه تدريجي2، کاهش زمان توسعه را به ارمغان آورده بودند، روشهاي تکاملي ديگر نيز چون روش اسپيرال3 و روشهاي تکراري4 با هدف مديريت بهتر تغييرات نيازمندي ها و ريسک توسعه پا به عرصه گذاشتند. روشهاي تکراري، پروژه را به چند بخش مجزا (قابل تکرار) تقسيم ميکردند که هر بخش مي‌توانست در يک تکرار به طور کامل توسعه و آماده تحويل گردد. اولين چرخه تکرار، با ابتدايي ترين بخشهاي قابل تحويل شروع مي‌شد و تکرارهاي بعد، ويژگي ها و کاربردهاي بيشتري را به آنها اضافه مي کردند. هر تکه از محصول از طريق روش آبشاري با بررسي نيازمنديهاي خاص آن بخش و پس از آن طراحي، پياده سازي و تست توسعه مي يافت. در واقع در هر تکرار، تنها نيازمنديهاي مربوط به همان تکرار مورد بررسي قرار ميگيرد و نيازي به بررسي کامل نيازمنديهاي کاربر در همه زمينه ها نيست و به همين دليل تا حدي اجازه بررسي بيشتر نيازمندي ها به کاربر داده مي‌شد. همچنين در مدل اسپيرال امکان اولويت بندي نيازمنديهاي کاربر نيز وجود دارد و اين امر تا حدي از ريسک پروژه ميکاهد. توسعه چرخشي (اسپيرال) و تکراري گام بزرگي در جهت چابک سازي فرايند آبشاري ارائه دادند. بسياري از صاحبنظران معتقدند که اين تکنيک نيز جوابگوي تغيير نيازمنديهاي کاربران نيست و پاسخگويي سريع به تغيير نيازمنديها امروزه امري حياتي و الزامي است.
2-3 بيانيه چابک
در ابتداي سال 2001، هفده تن از حاميان تفکر چابک در مهندسي نرم افزار، گرد هم آمدند تا به بررسي روشهاي جديد توسعه نرم افزار بپردازند. در پايان اين نشست آنها با تدوين و امضاي بيانيه اي که بيانيه چابک ناميده مي‌شود، رسماً روشهاي چابک را معرفي نمودند]2[. افراد حاضر در اين گردهمايي نمايندگان روشهاي چابکي بودند که قبلاً به صورت مجزا در حال بهبود فرايند توسعه نرم افزار بودند. برخي از اين روشها عبارتند از [1] :
Crystal, Scrum, Extreme Programming (XP), FDD, ASD, DSDM, Agile Modeling and Pragmatic Programming
اين افراد اذعان داشتند که حرکت به سوي چابکي يک ضد متدولوژي نيست، بلکه حرکت به سوي توازن توسعه نرم افزار و دادن اعتبار بيشتر به متدولوژي است. آنها در سخنان خود اشاره کردند که از مدلسازي استقبال مي‌کنند اما مخالف توليد فايلهاي متعدد و دياگرامهاي ناکارا هستند. همچنين از مستندسازي نيز استقبال خواهند کرد، اما نه از مستند سازي که منجر به توليد چند صد صفحه بلا استفاده و ناکارا باشد. برنامه ريزي نيز به صورتي که خلاصه و کارا باشد مورد تأئيد است. آنچه در اين ميان مشهود است تأکيد بر عوامل اصلي ناکارايي متدولوژي هاي پيشين در برخورد با واقعيت هاي جاري صنعت و ذي نفعان نرم افزار است. آنچه در اين گردهمايي متخصصين به چشم ميخورد اين بود که روشهايي که هر کدام ارائه مي‌دادند شايد در ظاهر داراي تعاريف و تمرينات و فعاليت هاي مخصوص به خود بودند ولي هدف و خاستگاه همه آنها دستيابي به ارزش هايي است که در روشهاي سنتي يا نمي توان به آنها رسيد يا دستيابي به آنها مستلزم هزينه و پيچيدگي بيشتر مي باشد.
اين افراد ضمن تأکيد بر مشترکات خود مبنايي غير فني و مستقل از فعاليت هاي مربوط به متدولوژي هاي توسعه نرم افزار را براي رسميت بخشيدن به روشهاي چابک بنا نهادند و طي يک بيانه مشترک که بيانيه چابک نامگذاري شد، رسالت اين متدولوژي ها را بيان کردند.
اين بيانيه به اين شرح است:

بيانيه چابک تبديل به بخش مهمي از حرکت (انقلاب) چابک گرديده است چرا که در آن ضمن برشمردن ارزشهاي چابک تفاوت چابکي با روشهاي سنتي نيز پررنگ شده است.
ارزش اول ارائه شده از آنجا ناشي مي‌شود که مهندسين نرم افزار در روشهاي سنتي بيش از حد درگير پيگيري فرايند هستند و ساختار اين متدولوژي ها نيز چنان است که توجه چنداني به افراد و نقش آنها در فرايند توسعه نشده است[13]. در حالي که امروزه اکثر دست اندر کاران صنعت نقش افراد را در توليد، پررنگ تر از فرايند مي‌دانند [13]. در خصوص ارزش دوم تأکيد بر خود نرم افزار نهايي است. اگرچه مستندات نيز اهميت خود را دارند، اما آنچه هدف نهايي فرايند توسعه نرم افزار است، محصول کاربردي است و در عمل هم تجربه چند دهه قبل نشانگر بلا استفاده بودن کوهي از مستندات توليد شده است. در بيان ارزش سوم، تأکيد بر روي رضايت مشتري است و آن را بر پيروي از قرارداد ارجح مي‌داند. در واقع ارزش محصول مناسب براي کاربر، فراتر از محصول ايجاد شده بر اساس قرارداد و عدم عدول از آن است. اين امر شايد منتقداني نيز داشته باشد [13] اما در نهايت با تعامل مناسب با مشتري ميتوان در قرارداد کاري نيز اجازه مانور به هر دو طرف داد. ارزش چهارم که شايد يکي از کليدي ترين مفاهيم چابک باشد، بر استقبال از تغييرات در برابر پيروي از يک برنامه تأکيد دارد. در واقع برنامه ريزي کامل که در مهندسي نرم افزار بر پايه تشخيص کامل نيازمنديها صورت ميپذيرد، ناقض و مانع چابکي فرايند در پاسخگويي به تغييرات نيازمنديها مي‌باشد .
عمده انتقاداتي که طرفداران روشهاي سنتي از روشهاي چابک دارند به اصول فوق برمي‌گردد. ، عمده نگراني هاي طرفداران روشهاي سنتي پيروي آنها از مدلهاي معروفي چون CMMI است که شايد در رويارويي با تفکر چابک در مواردي نفي گردند
در ادامه بيانيه چابک اصول دوازده گانه چابک به عنوان متمم آن و به شرح زير آمده اند.
اين اصول تا حدي نشانگر چارچوب فعاليت هاي مورد نياز براي دستيابي به اصول چابک هستند. فعاليت هاي چابک عمدتاً براي دستيابي به اين اصول طراحي و به کار گرفته مي‌شوند.

1. توسعه نرم افزار چابک

2-4 توسعه نرم افزار چابک
در اين قسمت به بررسي چابکي و روشهاي چابک منتخب خواهيم پرداخت.
چابکي5 به معناي واقعي
هدف از روشهاي چابک اين است که به سازمانها اجازه دهند که چابک باشند اما واقعا معناي چابکي چيست؟ در پاسخ به اين سوال نظرات متعددي ارائه شده است.
يک نظريه، چابکي را اينگونه تعبير مي کند ” تحويل سريع، تغيير سريع و تغيير دائم” . در حالي که روشهاي چابک در فعاليت ها و تأکيد بر ارزش ها متفاوت هستند اما در مواردي چون تأکيد بر توسعه تکراري، ارتباطات، کاهش محصولات غير ضروري يکسان هستند. توسعه نرم افزار در يک فرايند تکراري به تيم توسعه دهنده امکان تطبيق سريع با تغيير نيازمنديها را مي‌دهد. کار در يک مکان بسته و تأکيد بر ارتباطات به اين معني است که تيم مي‌تواند سريع تصميم گيري نموده و بر اساس اين تصميمات اقدام نموده و منتظر دريافت پاسخ و نظر از خارج سازمان نباشد. کاهش محصولات مياني که ارزش افزوده اي براي محصول نهايي و قابل ارائه ندارند، کمک مي‌کند که منابع بيشتري در بخش توسعه محصول اصلي صرف شده و در نتيجه محصول سريع تر توليد شود. بخش عمده اي از جنبش چابک مربوط به قدرت و توان برنامه نويس است [13, 14]. اين توانمندي اجازه مانور بيشتري به افراد در فرايند توسعه نرم افزار مي‌دهد [15]. اين دقيقا همان نقطه اي است که فرايند چابک مي‌تواند سريع تر به تغيير نيازمندي ها در مقايسه با روشهاي سنتي پاسخ دهد.
در نظريه ديگري در خصوص چابک سازي اشاره شده است که فعاليت هاي ارائه شده در فرايندهاي چابک چندان نشانگر چابکي نيست، بلکه چيزي که آنها را واقعا چابک مي کند، به رسميت شناختن افراد به عنوان عامل اصلي موفقيت پروژه به همراه تأکيد شديد بر کارايي و قابليت مانور آنها است [8].
همه صاحبنظران تأکيد دارند که چابک شدن صرفا به پيروي ساده از يک سري دستورالعملها نيست. چابکي واقعي فراتر از مجموعه اي از فعاليت ها است. چابکي واقعي يک چارچوب (قالب) فکري است. در واقع شايد با اجراي مجموعه اي از فعاليت ها به نظر برسد که چابک شده ايم اما چابکي را حس نخواهيم کرد[1, 15].
2-5 مجموعه اي از روشهاي چابک
روشهاي چابک در موارد متعددي چون ارزشها مشترک هستند، اما د

دیدگاهتان را بنویسید