الگو اسکرام


اسکرام یک روش چابکِ تکرارشونده و افزایشی برای مدیریت پروژه است که معمولاً در الگوی تولید نرم‌افزار چابک به عنوان نوعی متدولوژی توسعه نرم‌افزار دیده می‌شود. با اینکه روش اسکرام در واقع برای مدیریت محصولات تولید و توسعه پروژه‌ها پیشنهاد شده بود، اما استفاده آن در مدیریت پروژه‌های تولید نرم‌افزار متمرکز شد؛ همچنین امکان دارد جهت مدیریت تیم نگهداری نرم‌افزار، مدیریت پروژه‌ها یا برنامه‌های عمومی مدیریت خط مشی‌ها استفاده شود.








الگوهای بهبودسازی

الگوی تکامل قابلیت یکپارچه سازی (CMMI)

الگوی تکامل قابلیت یکپارچه‌سازی (CMMI) یکی از الگوهای پیشنهادی و تکنیک‌های پیشتاز است. ارزیابی سازمان‌های مستقل و رتبه‌بندی در مورد کیفیت چگونگی تعریف فرایندهای آن سازمان‌ها را دنبال می‌کند، نه بر کیفیت خود فرایندها یا نرم‌افزار تهیه شده است. الگوی CMMI جایگزین الگوی CMM شده است.








ایزو ۹۰۰۰

ایزو ۹۰۰۰ یک استاندارد رسمی سازماندهی فراینده ساخت محصولات و روشی برای مدیریت و نظارت پیشرفت کارهاست. در اصل این استاندارد برای بخش تولید وساخت(صنعتی) ایجاد شد.ایزو ۹۰۰۰ همچنین برای فرایند تولید نرم‌افزار نیز به خوبی استفاده شده.مانند الگو CMMI مدرک ایزو ۹۰۰۰ هیچ تضمینی راجع به کیفیت نتایج نهایی ندارد و فقط فرایندهای کاری را فرموله و قالب استاندارد رسمی می دهد.








ایزو ۱۵۵۰۴

ایزو ۱۵۵۰۴ که با عنوان فرایند تشخیص و تعیین بهبود قابلیت نرم‌افزار (به انگلیسی: Software Process Improvement and Capability Determination)(مخفف انگلیسی: SPICE) نیز شناخته می‌شود، چارچوبی برای ارزیابی فرایندهای نرم‌افزار است. این استاندارد تنظیمات قالب روشنی برای مقایسه فرایندها به شمار می‌رود. SPICE خیلی شبیه CMMI استفاده می‌شود. فرایندهای این الگو برای مدیریت، کنترل، راهنمایی و نظارت تولید نرم‌افزار است. این الگو جهت سنجش سازماندهی تولید و توسعه یا تیم پروژه بصورت واقعی در طول مدت تولید نرم‌افزار استفاده می‌شود. تجزیه و تحلیل این اطلاعات برای شناسایی نقاط ضعف و حرکت به سمت بهبود پروژه استفاه می‌شود. همچنین برای تشخیص نقاط قوت پروژه که می تواند برای سازمان یا تیم پروژه ادامه پیدا کند یا برای امور مشترک یکپارچه شود.







برنامه‌ریزی

برنامه ریزی، فرایندی برای رسیدن به اهداف است. بسته به فعالیتها، هر برنامه می تواند که بلند مدت، میان مدت یا کوتاه مدت باشد. برای مدیرانی که در جستجوی حمایت‌های بیرونی هستند، برنامه ریزی، مهمترین و کلیدی‌ترین سند برای رشد است.برنامه ریزی می تواند، نقش مهمی در کمک به جلوگیری از اشتباهات یا تشخیص فرصتهای پنهان بازی کند. برنامه ریزی به پیش بینی آینده و ساختن آینده تا حدودی قابل تصور کمک می کند. آن پلی است بین آنجایی که هستیم و آنجایی که می خواهیم برویم. برنامه ریزی به آینده می نگرد.

برنامه‌ریزی یا طرح‌ریزی یعنی اندیشیدن از پیش. متخصصین از زوایای متعدد برای برنامه‌ریزی تعاریف متعددی ارائه کرده‌اند که برخی از آنها از این قرار است:

تعیین هدف، یافتن و ساختن راه وصول به آن،
تصمیم‌گیری در مورد اینکه چه کارهایی باید انجام گیرد،
تجسم و طراحی وضعیت مطلوب در آینده و یافتن و ساختن راه‌ها و وسایلی که رسیدن به آن را فراهم کند،
طراحی عملیاتی که شیئی یا موضوعی را بر مبنای شیوه‌ای که از پیش تعریف شده، تغییر بدهد.

برنامه ریزی، نوعی پدیده عینی اجتماعی است و خصوصیت های ویژه خود را دارد در عین حال، یک رویداد منحصربه‌فرد نیست که دارای یک ابتدا و انتهای مشخص باشد بلکه یک فرایند مستمر و دائمی و منعکس کننده تغییرات و در صدد رسیدن به اهداف است. در سازمان های پیچیده امروزی، بدون برنامه ریزی های دقیق، امکان ادامه حیات نیست و برنامه ریزی، مستلزم آگاهی از فرصت ها و تهدیدهای آتی و پیش بینی شیوه مواجهه با آنها است.






مدیران، برنامه ریزی و تصمیم گیری

تصمیم گیری، رکن اساسی تمام وظایف مدیریتی و در عین حال، مبنای برنامه ریزی است چرا که نمی توان گفت برنامه ای وجود دارد مگر اینکه تصمیمی اتخاذ شده باشد. به عبارت بهتر، تصمیم گیری، هسته مرکزی مدیریت است که در تمامی وظایف دیگر، نموددارد، به همین دلیل برخی (مانند هربرت سایمون) مدیریت و تصمیم گیری را دو واژه مترادف می دانند!

به جرأت می توان گفت برنامه ریزی و تصمیم گیری، برای نیل به اهداف سازمان مکمل اند اما نوع اتخاذ تصمیم نیز نقش به سزایی ایفا می کند با وجودی که تصمیم گیری به کلیه وظایف مدیریتی مربوط می شود، اما اساس برنامه ریزی به شمار می آید و نمی توان گفت برنامه ای وجود دارد بدون اینکه تصمیمی گرفته شده باشد. از این رو، تصمیم گیری از ارکان اساسی فعالیت های مدیریتی به شمار می رود چرا که هر مدیری برای اجرای هریک از وظایف خود، همواره با مواردی مواجه می شود که نیاز به تصمیم گیری دارد.






برنامه ریزی به عنوان وظیفه مدیران

برنامه ریزی از وظایف بسیار مهم مدیران است و با سایر وظایف آنها ارتباطی تنگاتنگ دارد. اگر نگرش مبتنی بر برنامه ریزی در سراسر زندگی فردی و سازمانی تسری یابد، نوعی تعهد به عمل بر مبنای تعقل و تفکر آینده نگر و عزم راسخ بر استمرار آن ایجاد می شود. به نوعی، تحقق اهداف فردی و سازمانی، مستلزم برنامه ریزی است. نیاز به برنامه ریزی از آنجا است که همه سازمان ها با فعالیت در محیطی پویا، مترصد آن هستند که منابع محدودشان را برای رفع نیازهای متنوع و فزاینده خود صرف نمایند و این پویایی محیط و وجود تلاطم و عدم اطمینان ناشی از تغییرات محیطی، بر ضرورت انکار ناپذیر برنامه ریزی می افزاید.

با پذیرفتن اصول پنج گانه مدیریتی، و مبنای برنامه ریزی برای این اصول، به این اجماع نظر می رسیم که برنامه ریزی، فرایندی است دارای مراحل مشخص و بهم پیوسته برای تولید یک خروجی منسجم در قالب سیستمی هماهنگ از تصمیم هاکه در این فرایندی، مراحل مشخص و بهم پیوستهای برای تولید یک خروجی منسجم در قالب سیستمی هماهنگ از تصمیم ها وجود دارد. طی این فرایند، به پیش بینی و تدوین فعالیت هایی پرداخته می شود که باید در جهت نیل به اهداف سازمانی صورت گیرد. به عبارت بهتر در فرایند برنامه ریزی، به: چه کسی؟ کجا؟ کِی؟ چه چیزی؟ چرا؟ چگونه؟ پرداخته می شود و پاسخ به این پرسش ها به انتخاب مأموریت ها، هدف ها و اقداماتی برای نیل به آنها می انجامد که مستلزم تصمیم گیری و انتخاب از میان راه های مختلف است. برنامه ریزی می تواند، نقش مهمی در کمک به جلوگیری از اشتباهات یا تشخیص فرصت های پنهان بازی کند. برنامه ریزی به پیش بینی آینده و ساختن آینده تا حدودی قابل تصور کمک می کند. آن پلی است بین آنجایی که هستیم و آنجایی که می خواهیم برویم. برنامه ریزی به آینده می نگرد.






تعریف برنامه ریزی

نگاهی به واژه نامه های عمومی و تخصصی، کافی است تا تعاریفی از این دسته را پیش روی ما قرار دهد. اغلب واژه نامه های عمومی برنامه ریزی را کار یا فعالیت برنامه ریز؛ شکل گیری برنامه ها؛ ساخت یا ترسیم یک طرح یا نمودار؛ کشیدن طرح، طراحی، تدبیر کردن دانسته‌اند واژه نامه های تخصصی نیز آن را، شیوه و فرایند سیستماتیک و گام به گامی دانسته اند که به تعریف، ایجاد و ترسیم فعالیت های ممکنی می پردازد که با نیازها، علایق و مشکلات موجود یا آینده مطابقت داشته باشند

به عبارت دیگر، برنامه ریزی فرایندی است منظم مداوم وحساب شده ومنطقی جهت دار و دورنگر به منظورهدایت وارشاد فعالیتهای جمعی برای رسیدن به هدف مطلوب است .برنامه ریزی بایدمداومت داشته باشد. اهداف برنامه ریزی به شرح زیراست 1)پیش بینی آینده: برنامه آینده نگر 2)برنامه ساختن وشکل دادن به آینده: برنامه آینده ساز 3)برنامه برای انتخاب یک شکل خاص برای آینده :آینده گزین.

متخصصین ، برنامه ریزی را با توجه به حوزه ی فعالیت خود تعریف نموده اند. این واژه، در زمینه علوم و فنون بیشتر با واژه طراحی (designing) عجین شده. هر چند که:این برداشت تقلیل گرایانه و البته این واژه در متون مدیریتی جایگاهی ندارد!






مزایای برنامه ریزی

برخی از مزایای برنامه ریزی عبارتند از:

افزایش احتمال تحقق اهداف سازمان
ایجاد فرصتِ اجرای منظم تصمیم ها
صرفه اقتصادی
انطباق با شرایط متغیر محیطی
استفاده صحیح از منابع
فراهم شدن ابزارهای کنترل
امکان سنجش میزان پیشرفت
آگاهی کارکنان از اهداف سازمان و نقش خود
تقویت کار گروهی
رسیدن به اهداف شخصی

چالش های برنامه ریزی:

چالش های عمده برنامه ریزی از دید برخی منتقدان این امر عبارتند از:

1. حوادث غیر منتظره ای که می تواند تمام پیش بینی ها را نقش بر آب کند! 2.عوض شدن فکر

تغییر رویه هایی که ممکن است مقاومت ایجاد نماید.

1. صرف هزینه و وقت. 2. محدودیت های کوتاه مدت و مقطعی.






تصمیم گیری

واژه تصمیم در لغت به معنای عزم و اراده به انجام کاری است و از دید علم مدیریت، به معنای انتخاب یک راه از راه های مختلف و در حقیقت، انتخاب بهترین راه برای نیل به اهداف است. تصمیم گیری، بیش از آنکه کاری ساده باشد، فرایندی مرحله دار است.






گونه شناسی تصمیم گیری

گونه های مختلفی از تصمیم گیری را از دیدگاه های مختلف می توان شناسایی نمود. برخی از این گو نه ها عبارتند از:

تصمیم گیری به اعتبار برنامه (برنامه ریزی شده و برنامه ریزی نشده)
تصمیم گیری به اعتبار میزان اطلاعات
تصمیم گیری به اعتبار تصمیم گیرنده (فردی و گروهی)
تصمیم گیری به اعتبار درجه استقلال
تصمیم گیری به اعتبار میزان ساختار یافتگی
سایر موارد







مراحل تصمیم گیری

برآیند نسبتاً کلی از مراحلی که برای فرایند تصمیم گیری در متون مختلف طرح شده است را می توان در موارد زیر خلاصه نمود:

اطمینان از وجود نیاز به تصمیم
تعیین معیارهای تصمیم گیری
تشخیص میزان اهمیت معیارها
کشف راه حل ها
ارزیابی راه حل ها
انتخاب بهترین راه حل








برنامه‌سازی مفرط
برنامه‌سازی مفرط (به انگلیسی: extreme programming) که به اختصار XP نیز خوانده می‌شود، یک متدولوژی توسعه نرم‌افزار است که در آن هدف افزایش کیفیت نرم‌افزار و پاسخ‌گویی به نیازمندی‌های در حال تغییر کاربر است. به عنوان گونه‌ای از توسعه چابک نرم‌افزار (agile software development) از انتشار (release)های متناوب در چرخه‌های کوتاه توسعه با هدف بهبود قابلیت تولید و معرفی نقاط کنترلی (Check Point) برای تطابق با نیازمندی‌های جدید کاربر، دفاع می‌کند.








اسکرام
چارچوب یا فرایند مدل اسکرام یک چارچوب تکرارپذیر و افزایشی برای کنترل پروژه (مدیریت نرم‌افزار) است که معمولاً در زیر شاخه مدل فرایند تولید نرم‌افزار چابک و سریع است. و یک نوع مدل تولید نرم‌افزار در مهندسی نرم‌افزار بحساب می‌رود.اسکرام یک چارچوب تولید نرم‌افزار از سری روشهای تفکر چابک (Agile) می‌باشد. اسکرام یک چارچوب یا فرایند؟ مسئله این است، دراین موضوع کاملاً بین متخصصان اسکرام دوگانگی وجود دارد. اشخاصی مانند کن شوئبر (مبدع اسکرام) دائماً از لفظ چارچوب(framework) استفاده می‌کنند و تاکید می‌نمایند که همه باید این مورد را قبول داشته باشند ولی بعضی دیگر از دوستان از لفظ فرایند و یا متدولوژی برای اسکرام استفاده می‌کنند.






تاریخچه

این روش در سال ۱۹۸۶ توسط هیروتاکا تاکوچی و ایکوجیرو نوناکا بعنوان یک خط مشی جدید برای تولید نرم‌افزارهای تجاری که باید قابلیت سرعت در تولید و انعطاف پذیری را داشته باشند، عرضه شده گردید. اسم اسکرام از یک نوع بازی در فوتبال راگبی آمده است

اسکرام (Scurm) یک متدولوژی افزایشی (Incremental) برای مدیریت پروژه‌های نرم‌افزاری است و از رده متدولوژی‌های Agile محسوب می‌شود. این متدولوژی اولین بار در ژاپن اختراع شد و بعدها در سال ۱۹۹۱ توسط Stahl و Degrace توسعه داده شد. درسال ۱۹۹۵ این متدولوژی توسط Ken Schwober و Jeff Stherland بعنوان یک متدولوژی رسمی برای تولید نرم‌افزار بکار گرفته شد.






مشخصات

با اینکه روش اسکرام در واقع یک روش برای کل فرایند تولید نرم‌افزار در پروژه‌ها به شمار می‌رود اما اختصاصاً برای کنترل پروژه نرم‌افزار استفاده می‌گردد، همچنین امکان استفاده از این روش در نگهداری و پشتیبانی نرم‌افزار به عنوان برنامه و خط مشی عمومی وجود دارد.

اسکرام دربردارنده مجموعه‌ای از روش (Practice)ها و نقش‌های از قبل تعریف شده است اما سه ویژگی است که پایه‌های وجودی اسکرام هستند:

۱- شفافیت و روشنی Transparency: یعنی اینکه تمام جنبه‌های مختلف فرایند که بر خروجی آن اثر می‌گذارد بایستی برای آنهایی که فرایند را کنترل می‌کنند مشهود و قابل دید باشد. نه فقط این جنبه‌ها باید شفاف باشد بلکه بایستی مشخص و معلوم هم باشند یعنی اگر کسی که فرایند را ممیزی می‌کند تشخیص دهد که چه چیزی انجام شده، این باید مطابق با تعریف انجام شده Done از دید تمام افراد درگیر در پروژه باشد. اگر توافقی بین همه طرف‌های درگیر در پروژه بر سر معانی و مفاهیم نباشد، مشهود بودن اینکه یک قابلیت یا ویژگی انجام شده یا خیر، دیگر محلی از اعراب ندارند.

۲- ممیزی و وارسی Inspection: جنبه‌های مختلف فرایند تولید نرم‌افزار بایستی مدام به اندازه‌ای در حال وارسی و چک باشند که انحرافات فرایند قابل تشخیص باشد.

۳- انطباق Adaption: اگر بازرس و ممیز فرایند پس از بازرسی فرایند، تشخیص داد که یک یا چند جنبه از فرایند خارج از حدود قابل قبول است و باعث غیر قابل پذیرش شدن محصول تولیدی می‌شود، آن شخص باید فرایند یا آنچه که فرایند بر روی آن انجام می‌شود را تنظیم و تعدیل کند. این کار باید در سریعترین زمان ممکنه انجام شود تا از انحرافات بیشتر جلوگیری شود.






نقشها

نقش‌های عمده در اسکرام عبارتند از:

ScrumMaster که وظیفه نگهداری و حفظ فرایند را برعهده دارد.
Product Owner که نماینده ذینفعان (Stakeholders)های پروژه و business است.
Team Member عضوی از یک گروه cross-function است که معمولاً بیش از ۷ نفر نیستند. این افراد عملیات تحلیل٫ طراحی٫ پیاده سازی، تست و... را انجام می‌دهند.

تعریف هر نوع نقش یا سمت به جز سه نقش گفته شده در اسکرام ممنوع است. به عنوان مثال اعضای تیم نمی‌توانند سمت‌های متفاوتی داشته باشند.
روند کار اسکرام

مثل تمام متدولوژی‌های Incremental و Iterative اینجا هم ما دوره‌های زمانی یا iteration داریم که در طی آنها محصول نهایی پروژه بتدریج تکمیل می‌شود. این دوره‌های زمانی را در اسکرام اصطلاحاً sprint نامیده می‌شوند.

در طی یک Sprint که معمولاً یک دوره دو تا چهار هفته است (طول دوره را تیم مشخص می‌کند) اعضاء تیم یک محصول بالقوه قابل ارائه و قابل استفاده را تدریجاً تولید می‌کنند. بطور رسمی دوره هر sprint یک ماه یا سی روز در نظر می‌گیرند.

مجموعه ویژگی‌هایی از محصول نهایی پروژه که در یک sprint محقق می‌شود از یک Requirements Repository بنام Sprint Backlog استخراج می‌شود.

اصطلاح Product Backlog نامی است که به بانک اطلاعاتی نیازمندهای عملیاتی و غیر عملیاتی کل یک پروژه اطلاق می‌شود و در حقیقت مجموعه‌ای اولویت بندی شده از نیازمندی‌های سطح بالای سیستمی است که در نهایت بایستی تحویل داده شود.







Sprint Planning Meeting

مواردی از Product Backlog که در طی یک sprint بایستی انجام شود در طول جلسه برنامه ریزی sprint مشخص می‌شود. اصطلاحاً این جلسه را Sprint Planning Meeting می‌نامند.

در طول این جلسه، Product Owner اعضاء تیم را دربارهٔ مواردی از Product Backlog محصولی که می‌خواهند تکمیل شود، آگاه می‌کند. سپس اعضاء تیم مشخص می‌کنند که چه مقدار از موارد مشخص شده توسط Product Owner را می‌توانند در این sprint انجام دهند و چه میزان از آنرا در sprintهای بعدی.

مواردی از Product Backlog که قرار است در یک Sprint انجام شود را اصطلاجاْ Sprint Backlog می‌نامند. مفاد Sprint Backlog در واقع توافقی است بین اعضاء تیم و Product Owner برای انجام بخشی از نیازمندی‌های پروژه در طول sprint جاری و بهرحال طبیعی است که بعد از تصویب شدن مفاد یک sprint، هیچکس نمی‌تواند آنرا در طول sprint تغییر دهد. در طول دوره، نیازمندی‌های لحاظ شده در Sprint Backlog از Product Backlog بر داشته می‌شوند. اما امکان دارد به دلایلی که در ادامه می‌آید این نیازمندی‌های دوباره به Product Backlog برگردد.

مانند تمام متدولوژی‌های iterative توسعه نرم‌افزار در اسکرام نیز Time Boxed است، به این معنی که sprint بایستی دقیقاً سروقت تمام شود و اگر نیازمندی‌های اشاره شده در Spring Backlog به هر علتی تکمیل نشده باشند آنها را کنار گذاشته و دوباره وارد Product Backlog می‌کنند.

بعد از خاتمه یک sprint، اعضاء تیم طی جلسه‌ای به Product Owner و سایر ذینفعان پروژه نشان می‌دهند که چکار کرده‌اند و چطور از نسخه جاری نرم‌افزار می‌شود استفاده کرد.

در ساده‌ترین روش معمولاً از نرم‌افزارهای صفحه گستره (Spread Sheet) همچون LibreOffice Calc یا Microsoft Excel برای ساختن و نگهداری Product Backlog و Sprint Backlog استفاده می‌شود، اما می‌توان از طیف وسیعی از ابزارهای نرم‌افزاری که برای استفاده در تیمهای Agile نوشته شده‌اند نیز استفاده کرد.








توسعه‌دهنده نرم‌افزار

تولیدکننده نرم‌افزار یا توسعه‌دهنده نرم‌افزار (به انگلیسی: Software developer) در مبحث توسعهٔ نرم‌افزار به هر کسی اطلاق می‌شود که بخشی از فرایند تولید نرم‌افزار را برعهده داشته باشد. یعنی هر یک از موقعیت‌های زیر جزو توسعه‌دهندگان محسوب می‌شوند:

مدیر پروژهٔ نرم‌افزار
تحلیل‌گر کسب و کار نرم‌افزار
طراح نرم‌افزار
برنامه‌نویس
آزمون‌گر نرم‌افزار

برای هر برنامه یا نرم‌افزاری ممکن است تمام یا بخشی از اعضای این تیم حاضر باشند.







توسعه نرم‌افزاری چابک

توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت می‌کند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد. مانیفست چابک در سال ۲۰۰۱ این اصطلاح را معرفی کرد.






تاریخچه
سوابق

متدهای توسعهٔ افزایشی نرم‌افزار به سال ۱۹۵۷ برمی‌گردند. در سال 1974، E.A. Edmonds در مقاله‌ای فرایند توسعهٔ تطبیقی نرم‌افزار را معرفی کرد. هم‌زمان و به طور مستقل متدهای مشابه توسعه یافت و توسط مرکز توسعهٔ سیستم‌های شرکت تلفن نیویورک زیر نظر Dan Gielan گسترش یافت. اوایل دههٔ 1970، Tom Gilb شروع به انتشار مفاهیمی در مورد کنترل تحولی پروژه (EVO) کرد، که به مهندسی رقابتی توسعه یافت. در طول نیمه تا انتهای دههٔ 1970 Gielan به طور گسترده در ایالات متحده در مورد این متدولوژی، تجارب و فواید آن سخنرانی‌هایی ارائه داد.

متدهای توسعهٔ به اصطلاح چالاک و چابک نرم‌افزار اواسط دههٔ ۱۹۹۰ به صورت یک عکس‌العمل در مقابل متدهای سنگین آبشاری مطرح شد، که توسط منتقدان آن به صورت یک مدل توسعهٔ به شدت منظم، دسته‌بندی‌شده، میکرو مدیریتی و آبشاری توصیف شده است. استدلال‌کنندگان متدهای چالاک و چابک ادعا می‌کنند، این متدها به منزلهٔ بازگشت به تجارب توسعهٔ نرم‌افزار در اوایل تاریخ هستند. پیاده‌سازی‌های اولیهٔ متدهای چابک، شامل Rational Unified Process (1994)، Scrum (1995)، Crystal Clear، برنامه‌نویسیExtreme (1996)، توسعهٔ تطبیقی نرم‌افزار، توسعهٔ ویژگی‌محور و متد توسعهٔ سیستم‌های دینامیک (DSDM، 1995) می‌شود. بعد از انتشار مانیفست چابک در سال ۲۰۰۱، اکنون این‌ها به طور معمول به متدولوژی‌های چابک برمی‌گردند.






مانیفست چابک

در فوریهٔ ۲۰۰۱، تعداد ۱۷ توسعه‌دهنده‌ی نرم‌افزار، در Snowbird یوتا ملاقاتی داشتند تا در مورد متدهای توسعه‌ی چالاک گفتگو کنند.

آنها برای توصیف رویکردی که اکنون به عنوان «توسعه‌ی چابک نرم‌افزار» شناخته می‌شود، مانیفستی برای توسعه‌ی چابک نرم‌افزار منتشر کردند. بعضی از نویسندگان این مانیفست اتحاد Agile را ایجاد کردند ، یک سازمان غیرانتفاعی که توسعه‌ی نرم‌افزار را بر اساس اصول مانیفست ترویج می‌دهند.







تمام مانیفست چابک به شرح زیر است:

ما با توسعه نرم‌افزار و کمک به دیگران در انجام آن، در حال کشف راه های بهتری برای توسعه نرم‌افزار هستیم. از این کار به ارزش های زیر می­رسیم :

۱- افراد و تعاملات بالاتر از فرایندها و ابزارها

۲- نرم‌افزار کار کننده بالاتر از مستندات جامع

۳- مشارکت مشتری بالاتر از قرارداد کاری

۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.

معنی آیتم‌های سمت راست مانیفست در مفهوم توسعه‌ی چابک نرم‌افزار در زیر توضیح داده شده است:






افراد و تعاملات بالاتر از فرایندها و ابزارها

افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرایند عالی بدون نیروی مناسب منجر به شکست می­گردد و بر عکس افراد قوی تحت فرایند ضعیت ناکارآمد خواهند بود.

یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.

در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال می­توانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفاً به آنها به عنوان امکانی جهت تسهیل فرایندها نگاه کنید.






نرم‌افزار کار کننده بالاتر از مستندات جامع

نرم‌افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم‌افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.

با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را می گیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم می شوند.

بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.

اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه می توانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال می­دهیم. ما آنها را بخشی از تیم می­کنیم و با تعامل نزدیک و رو در رو به آنها آموزش می­دهیم.






مشارکت مشتری بالاتر از قرارداد کاری

نرم‌افزار نمی­تواند مثل یک جنس سفارش داده شود. شما نمی‌توانید یک توصیف از نرم‌افزاری که می خواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.

این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده می کند، بسازند. اما این تعامل به کیفیت پایین نرم‌افزار و در نهایت شکست آن می انجامد. پروژه های موفق بر اساس دریافت بازخورد مشتری در بازه های زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتباً اعمال نظر می­کند.

قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساساً نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.
پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه

توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم‌افزاری است. وقتی که طرحی را می­ریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.

مسیر یک پروژه نرم‌افزاری نمی­تواند برای بازه زمانی طولانی برنامه ریزی شود. اولاً احتمالاً محیط تغییر می­کند و باعث تغییر در نیازمندی ها می­شود. ثانیاً همین که سیستم شروع به کار کند مشتریان نیازمندی­های خود را تغییر می دهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمی­کنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.

یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.






اصول چابک

بر اساس نظرات Kent Beck، مانیفست چابک، بر ۱۲ اصل استوار است:

رضایت مشتری از طریق تحویل سریع نرم‌افزار مفید؛
استقبال از تغییرات نیازمندی‌ها، حتی در اواخر توسعه؛
نرم‌افزار کار زود به زود تحویل می‌شود (هفتگی به جای ماهانه)؛
نرم‌افزار کار مقیاس اصلی پیشرفت است؛
توسعه‌ی پایدار، قادر به حفظ سرعت ثابت است؛
همکاری نزدیک و روزانه بین افراد کسب‌وکار و تیم توسعه؛
مکالمه‌ی رو در رو بهترین شکل ارتباطات است (محل مشترک)؛
پروژه‌ها در اطراف افراد باانگیزه، که باید به آنها اعتماد کرد، شکل می‌گیرند؛
توجه مستمر به برتری فنی و طراحی خوب؛
سادگی- هنر به حداکثر رساندن کارهای انجام‌نشده- ضروری است؛
تیم‌های خودسازمان‌دهی؛
انطباق با تغییرات محدودیت‌ها به طور منظم.

در سال ۲۰۰۵، گروهی به ریاست Alistair Cockburn و Jim Highsmith ضمیمه‌ای تحت عنوان «اعلامیه‌ی وابستگی» برای اصول مدیریت پروژه نوشتند، که مدیریت پروژه‌های نرم‌افزاری را بر اساس متدهای توسعه‌ی نرم‌افزار پیش ببرد..






مشخصات

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

متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین 5 تا 9 نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌کند، افراد ارتباط روزانه‌شان را از طریق ویدئو کنفرانس، صدا، ایمیل و... حفظ می‌کنند.

مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد. در انتهای هر تکرار، ذی‌نفعان و نماینده‌ی مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیر رسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به طور خاص شامل نماینده‌ی مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسه‌ی مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت بر‌گزار می‌شوند و نباید بیش از 15 دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»

توسعه‌ی چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.

ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعه‌ی آزمون‌محور، الگوهای طراحی، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.

توسعه‌ی کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجه‌ی اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آنها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.

در توسعه‌ی چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول(های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعه‌ی چابک نرم‌افزار» در سال 2002 توصیف شد. ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.
1:49 am
کاربرد برنامه نویسی

زبان برنامه نویسی یک مکانیزم ساخت یافته برای تعریف داده‌ها، و عملیات یا تبدیل‌هایی که ممکن است بطور اتوماتیک روی آن داده انجام شوند، فراهم می‌کند. یک برنامه نویس از انتزاعات آماده در زبان استفاده می‌کند تا مفاهیم به کار رفته در محاسبات را بیان کند. این مفاهیم به عنوان یک مجموعه از ساده‌ترین عناصر موجود بیان می‌شوند(مفاهیم ابتدایی نامیده می‌شوند).





زبان‌های برنامه نویسی با غالب زبان‌های انسانی تفاوتی دارد و آن این است که نیاز به بیان دقیق تر و کامل تری دارد. هنگام استفاده از زبان‌های طبیعی برای ارتباط با دیگر انسان‌ها، نویسندگان و گویندگان می‌توانند مبهم باشند و اشتباهات کوچک داشته باشند، و همچنان انتظار داشته باشند که مخاطب آنها متوجه شده باشد. اگرچه، مجازا، رایانه‌ها "دقیقاً آنچه که به آنها گفته شده را انجام می‌دهند." و نمی‌توانند "بفهمند" که نویسنده دقیقاً چه کدی مد نظر نویسنده بوده‌است] البته امروزه برنامه‌هایی برای انجام این کار تولید شده‌اند و تلاش‌های بسیاری در این زمینه انجام شده ولی هنوز به نتیجهٔ رضایت بخشی نرسیده است[. ترکیب تعریف زبان، یک برنامه، و ورودی برنامه بطور کامل رفتار خروجی را به هنگام اجرای برنامه (در محدوده کنترل آن برنامه) مشخص می‌کند. برنامه‌های یک رایانه ممکن است در یک فرایند ناپیوسته بدون دخالت انسان اجرا شوند، یا یک کاربر ممکن است دستورات را در یک مرحله فعل و انفعال مفسر تایپ کند.در این حالت "دستور"ها همان برنامه‌ها هستند، که اجرای آنها زنجیروار به هم مرتبطند.به زبانی که برای دستور دادن به برنامه‌ای استفاده می‌شود، زبان اسکریپت می‌گویند. بسیاری از زبان‌ها کنار گذاشته شده‌اند، برای رفع نیازهای جدید جایگزین شده‌اند، با برنامه‌های دیگر ترکیب شده‌اند و در نهایت استعمال آنها متوقف شده‌است. با وجود اینکه تلاش‌هایی برای طراحی یک زبان رایانه" کامل" شده‌است که تمام اهداف را تحت پوشش قرار دهد، هیچ یک نتوانستند بطور کلی این جایگاه را پر کنند. نیاز به زبان‌های رایانه‌ای گسترده از گستردگی زمینه‌هایی که زبان‌ها استفاده می‌شوند، ناشی می‌شود:

محدوده برنامه‌ها از متون بسیار کوچک نوشته شده توسط افراد عادی تا سیستم‌های بسیار بزرگ نوشته شده توسط صدها برنامه نویس است
توانایی برنامه نویس‌ها: از تازه کارهایی که بیش از هر چیز به سادگی نیاز دارند تا حرفه‌ای‌هایی که با پیچیدگی قابل توجهی کنار می‌آیند.
برنامه‌ها باید سرعت، اندازه و سادگی را بسته به سیستم‌ها از ریزپردازندها تا ابر رایانه‌ها متناسب نگه دارند.
برنامه‌ها ممکن است یک بار نوشته شوند و تا نسل‌ها تغییر نکنند، و یا ممکن است پیوسته اصلاح شوند.
در نهایت، برنامه نویس‌ها ممکن است در علایق متفاوت باشند: آنها ممکن است به بیان مسائل با زبانی خاص خو گرفته باشند.

یک سیر رایج در گسترش زبان‌های برنامه نویسی این است که قابلیت حل مسائلی با درجات انتزاعی بالاتری را اضافه کنند. زبان‌های برنامه نویسی اولیه به سخت‌افزار رایانه گره خورده بودند. همانطور که زبان‌های برنامه نویسی جدید گسترش پیدا کرده‌اند، ویژگی‌هایی به برنامه‌ها افزوده شده که به برنامه نویس اجازه دهد که ایده‌هایی که از ترجمه ساده به دستورات سخت‌افزار دورتر هستند نیز استفاده کند. چون برنامه نویس‌ها کمتر به پیچیدگی رایانه محدود شده‌اند، برنامه‌های آنها می‌تواند محاسبات بیشتری با تلاش کمتر از سوی برنامه نویس انجام دهند. این به آنها این امکان را می‌دهد که کارایی بیشتردر واحد زمان داشته باشند. "پردازنده‌های زبان طبیعی" به عنوان راهی برای ازبین بردن نیاز به زبان‌های اختصاصی برنامه نویسی پیشنهاد شده‌اند. هرچند، این هدف دور است و فواید آن قابل بحث است. "ادسگر دیجسترا" موافق بود که استفاده از یک زبان رسمی برای جلوگیری از مقدمه سازی ساختارهای بی معنی واجب است، و زبان برنامه نویسی طبیعی را با عنوان "احمقانه" رد کرد، "آلن پرلیس" نیز مشابها این ایده را رد کرد. مطابق با متدولوژی نامتجانس استفاده شده توسط langpop.com در سال ۲۰۰۸، ۱۲ زبان پرکاربرد عبارتند از: C, C++, C#, Java, JavaScript, Perl, PHP, Python, Ruby, Shell, SQL, and Visual Basic.



المان‌ها
تمام زبان‌های بزنامه نویسی تعدادی بلوک‌های ابتدایی برای توضیح داده و پردازش یا تبدیل آنها(مانند جمع کردن دو عدد با انتخاب یک عضو از یک مجموعه)دارند. این " عناصرابتدایی" بوسیله قوانین معناشناسی و دستوری تعریف می‌شوند که ساختار و معنای مربوطه را توضیح می‌دهند.
دستور(
syntax)

فرم سطحی یک زبان برنامه نویسی دستور آن نامیده می‌شود. غالب زبان‌های برنامه نویسی کاملاً متنی اند؛ و از دنبالهٔ متون شامل کلمات، اعداد، نشانگذاری، بسیار شبیه زبان نوشتاری طبیعی استفاده می‌کنند. از طرف دیگر، برنامه‌هایی نیز وجود دارند که بیشتر گرافیکی اند، و از روابط بصری بین سمبل‌ها برای مشخص کردن برنامه استفاده می‌کنند. دستور یک زبان ترکیبات ممکن سمبل‌ها برای ایجاد یک برنامهٔ درست را از نظر دستوری مشخص می‌کند. معنایی که به یک ترکیب سمبل‌ها داده می‌شود با معناشناسی اداره می‌شود(قراردادی یا نوشته شده در پیاده سازی منبع). از آنجا که اغلب زبان‌ها متنی هستند، این مقاله دستور متنی را مورد بحث قرار می‌دهد.

دستور زبان برنامه نویسی معمولاً بوسیله ترکیب عبارات معین(برای ساختار لغوی) و فرم توضیح اعمال(برای ساختار گرامری) تعریف می‌شوند. متن زیر یک گرامر ساده، به زبان lisp است: expression ::= atom | list atom ::= number | symbol number ::= [+-]?['۰'-'۹']+ symbol ::= ['A'-'Za'-'z'].* list ::= '(' expression* ')' این گرامر موارد ذیل را مشخص می‌کند:

یک عبارت یا atom است و یا یک لیست
یک atom یا یک عدد است و یا یک سمبل
یک عدد دنباله ناشکسته‌ای از یک یا تعداد بیشتری اعداد دهدهی است، که یک علامت مثبت و یا منفی می‌تواند پیش از آن بیاید.
یک سمبل حرفی است که بعد از هیچ یا تعدادی کاراکتر (جز فاصله) می‌آید.
یک لیست تعدادی پرانتز است که می‌تواند صفر یا چند عبارت در خود داشته باشد.

"۱۲۳۴۵"، "()"، "(a b c۲۳۲ (۱))" مثال‌هایی هستند از دنباله‌های خوش فرم در این گرامر.

همه برنامه‌هایی که از لحاظ دستوری درست هستند، از نظر معنا درست نیستند. بسیاری از برنامه‌های درست دستوری، بد فرم اند، با توجه به قوانین زبان؛ و ممکن است (بسته به خصوصیات زبان و درست بودن پیاده سازی) به خطای ترجمه و یا استثنا(exception) منتج شود. در برخی موارد، چنین برنامه‌هایی ممکن است رفتار نامشخصی از خود نشان دهند. حتی اگر یک برنامه در یک زبان به خوبی بیان شده باشد، ممکن است دقیقاً مطلوب نویسنده آن نبوده باشد.

به عنوان مثال در زبان طبیعی، ممکن نیست به برخی از جملات درست از لحاظ گرامری، معنای خاصی اطلاق کرد و یا ممکن است جمله نادرست باشد:

"ایده‌های بی رنگ سبز با خشم می‌خوابند."از نظر دستوری خوش فرم است ولی معنای مورد قبولی ندارد.
"جان یک مجرد متاهل است." از نظر دستوری درست است، ولی معنایی را بیان می‌کند که نمی‌تواند درست باشد.

این قسمت از زبان C از نظر دستوری درست است، اما دستوری را انجام می‌دهد که از نظرمعنایی تعریف نشده است(چون p یک اشاره گر خالی است، عمل p->real,p->im معنای خاصی ندارد.) complex *p = NULL; complex abs_p = sqrt (p->real * p->real + p->im * p->im);

گرامر مورد نیاز برای مشخص کردن یک زبان برنامه نویسی می‌تواند با جایگاهش در "سلسله مراتب چامسکی" طبقه بندی شود. دستور اغلب زبان‌های برنامه نویسی می‌تواند بوسیله یک گرامر نوع ۲ مشخص گردد، برای مثال، گرامرهای مستقل از متن.




معناشناسی ایستا
معناشناسی ایستا محدودیت‌هایی بر روی ساختار مجاز متن‌ها تعیین می‌کند که بیان آنها در فرمول دستوری استاندارد مشکل و یا غیر ممکن است. مهمترین این محدودیت‌ها به وسیله سیستم نوع گذاری انجام می‌شود.


سیستم نوع گذاری
یک سیستم نوع گذاری مشخص می‌کند که یک زبان برنامه نویسی چگونه مقادیر و عبارات را در نوع(type) دسته بندی می‌کند، چگونه می‌تواند آن نوع‌ها را تغییر دهد و رفتار متقابل آن‌ها چگونه‌است. این کارعموما توضیح داده ساختارهایی که می‌توانند در آن زبان ایجاد شوند را شامل می‌شود. طراحی و مطالعه سیستم‌های نوع گذاری بوسیله ریاضیات قراردادی را تئوری نوع گذاری گویند.
زبان‌های نوع گذاری شده و بدون نوع گذاری

یک زبان نوع گذاری شده‌است اگر مشخصات هر عملیات، نوع داده‌های قابل اجرا توسط آن را با نشان دادن نوع‌هایی که برای آنها قابل اجرا نیست، تعیین کند. برای مثال، "این متن درون گیومه قرار دارد" یک رشته‌است. در غالب زبان‌های برنامه نویسی، تقسیم یک رشته با یک عدد معنایی ندارد. در نتیجه غالب زبان‌های برنامه نویسی مدرن ممکن است اجرای این عملیات را توسط برنامه‌ها رد کنند. در برخی زبان‌ها، عبارات بی معنی ممکن است هنگام ترجمه(compile) پیدا شود(چک کننده نوع ایستا)، و توسط کامپایلر رد شود، در حالی که در سایر برنامه‌ها، هنگام اجرا پیدا شود.(چک کننده نوع دینامیک) که به استثنای در حال اجرا منتج شود(runtime exception). حالت خاص زبان‌های نوع دار زبان‌های تک نوعند. این زبان‌ها غالباً اسکریپتی و یا مارک آپ هستند، مانند rexx وSGML و فقط یک داده گونه دارند—غالباً رشته‌های کاراکتری که هم برای داده‌های عددی و هم برای داده‌های سمبلی کاربرد دارند. در مقابل، یک زبان بدون نوع گذاری، مثل اکثر زبان‌های اسمبلی، این امکان را می‌دهد که هر عملیاتی روی هر داده‌ای انجام شود، که معمولاً دنباله‌ای از بیت‌ها با طول‌های متفاوت در نظر گرفته می‌شوند. زبان‌های سطح بالا که بی نوع هستند شامل زبان‌های ساده رایانه‌ای و برخی از انواع زبان‌های نسل چهارم.

در عمل، در حالیکه تعداد بسیار کمی از دیدگاه نظریه نوع، نوع گذاری شده تلقی می‌شوند(چک کردن یا رد کردن تمام عملیات‌ها)، غالب زبان‌های امروزی درجه‌ای از نوع گذاری را فراهم می‌کنند. بسیاری از زبان‌های تولیدکننده راهی را برای گذشتن یا موقوف کردن سیستم نوع فراهم می‌کنند.



نوع گذاری ایستا و متحرک

در نوع گذاری ایستا تمام عبارات نوع‌های خود را قبل از اجرای برنامه تعیین می‌کنند(معمولاً در زمان کامپایل). برای مثال، ۱ و (۲+۲) عبارات عددی هستند؛ آنها نمی‌توانند به تابعی که نیاز به یک رشته دارد داده شوند، یا در متغیری که تعریف شده تا تاریخ را نگه دارد، ذخیره شوند.


زبان‌های نوع گذاری شده ایستا می‌توانند با مانیفست نوع گذاری شوند یا با استفاده از نوع استنباط شوند. در حالت اول، برنامه نویس بیشتر صریحاً نوع‌ها را در جایگاه‌های منتنی مشخص می‌نویسد(برای مثال، در تعریف متغیرها). در حالت دوم، کامپایلر نوع عبارات و تعریف‌ها را بر اساس متن استنباط می‌کند. غالب زبان‌های مسیر اصلی(mainstream) ایستا نوع گذاری شده، مانند C#,C++ و Java، با مانیفست نوع گذاری می‌شوند



نوع گذاری قوی و ضعیف

نوع گذاری ضعیف این امکان را ایجاد می‌کند که با متغیری به جای متغیری دیگر برخورد شود، برای مثال رفتار با یک رشته به عنوان یک عدد. این ویژگی بعضی اوقات ممکن است مفید باشد، اما ممکن است باعث ایجاد برخی مشکلات برنامه شود که موقع کامپایل و حتی اجرا پنهان بمانند.

نوع گذاری قوی مانع رخ دادن مشکل فوق می‌شود. تلاش برای انجام عملیات روی نوع نادرست متغیر منجر به رخ دادن خطا می‌شود. زبان‌هایی که نوع گذاری قوی دارند غالباً با نام "نوع-امن" و یا امن شناخته می‌شوند. تمام تعاریف جایگزین برای "ضعیف نوع گذاری شده" به زبان‌ها اشاره می‌کند، مثل perl, JavaScript, C++، که اجازه تعداد زیادی تبدیل نوع داخلی را می‌دهند. در جاوااسکریپت، برای مثال، عبارت ۲*x به صورت ضمنی x را به عدد تبدیل می‌کند، و این تبدیل موفقیت آمیز خواهد بود حتی اگر x خالی، تعریف نشده، یک آرایه، و یا رشته‌ای از حروف باشد. چنین تبدیلات ضمنی غالباً مفیدند، اما خطاهای برنامه نویسی را پنهان می‌کنند.

قوی و ایستا در حال حاضر عموماً دو مفهوم متعامد فرض می‌شوند، اما استفاده در ادبیات تفاوت دارد، برخی عبارت "قوی نوع گذاری شده" را به کار می‌برند و منظورشان قوی، ایستایی نوع گذاری شده‌است، و یا، حتی گیچ کننده تر، منظورشان همان ایستایی نوع گذاری شده‌است. بنابراین C هم قوی نوع گذاری شده و هم ضعیف و ایستایی نوع گذاری شده نامیده می‌شود.



معناشناسی اجرا

وقتی که داده مشخص شد، ماشین باید هدایت شود تا عملیات‌ها را روی داده انجام دهد. معناشناسی اجرا ی یک زبان تعیین می‌کند که چگونه و چه زمانی ساختارهای گوناگون یک زبان باید رفتار برنامه را ایجاد کنند.

برای مثال، معناشناسی ممکن است استراتژی را که بویسله آن عبارات ارزیابی می‌شوند را تعریف کند و یا حالتی را که ساختارهای کنترلی تحت شرایطی دستورها را اجرا می‌کنند.


کتابخانه هسته
اغلب زبان‌های برنامه نویسی یک کتابخانه هسته مرتبط دارند(گاهی اوقات "کتابخانه استاندارد" نامیده می‌شوند، مخصوصا وقتی که به عنوان قسمتی از یک زبان استاندارد ارائه شده باشد)، که به طور قراردادی توسط تمام پیاده سازی‌های زبان در دسترس قرار گرفته باشند. کتابخانه هسته معمولاً تعریف الگوریتم‌ها، داده ساختارها و مکانیزم‌های ورودی و خروجی پرکاربرد را در خود دارد. کاربران یک زبان، غالباً با کتابخانه هسته به عنوان قسمتی از آن رفتار می‌کنند، اگرچه طراحان ممکن است با آن به صورت یک مفهوم مجزا رفتار کرده باشند. بسیاری از خصوصیات زبان هسته‌ای را مشخص می‌کنند که باید در تمام پیاده سازی‌ها موجود باشند، و در زبان‌های استاندارد شده این کتابخانه هسته ممکن است نیاز باشد. بنابراین خط بین زبان و کتابخانه هسته آن از زبانی به زبان دیگر متفاوت است. درواقع، برخی زبان‌ها به گونه‌ای تعریف شده‌اند که برخی از ساختارهای دستوری بدون اشاره به کتابخانه هسته قابل استفاده نیستند. برای مثالف در جاوا، یک رشته به عنوان نمونه‌ای از کلاس “java.lang.String” تعریف شده است؛ مشابها، در سمال تاک(smalltalk) یک تابع بی نام(یک "بلاک") نمونه‌ای از کلاس BlockContext کتابخانه می‌سازد. بطور معکوس، Scheme دارای چندین زیرمجموعه مرتبط برای ایجاد سایر ماکروهای زبان می‌باشد، و در نتیجه طراحان زبان حتی این زحمت را نیز تحمل نمی‌کنند که بگویند کدام قسمت زبان به عنوان ساختارهای زبان باید پیاده سازی شوند، و کدام یک به عنوان بخشی ازکتابخانه.


عمل
طراحان زبان و کاربران باید مصنوعاتی ایجاد کنند تا برنامه نویسی را در عمل ممکن سازند و کنترل کنند. مهمترین این مصنوعات خصوصیات و پیاده سازی‌های زبان هستند.



خصوصیات

یک زبان برنامه نویسی باید تعریفی فراهم کند که کاربران و پیاده کننده‌های زبان می‌توانند از آن استفاده کنند تا مشخص کنند که رفتار یک برنامه درست است. با داشتن کد منبع: خصوصیات یک زبان برنامه نویسی چندین قالب می‌تواند بگیرد، مانند مثال‌های زیر:

تعریف صریح دستور، معناشناسی ایستا، ومعناشناسی اجرای زبان. درحالیکه دستور معمولاً با یک معناشناسی قراردادی مشخص می‌شود، تعاریف معناشناسی ممکن است در زبان طبیعی نوشته شده باشند (مثل زبان C)، یا معناشناسی قراردادی(مثل StandardML ,Scheme)
توضیح رفتار یک مترجم برای زبان(مثل C,fortran). دستور و معناشناسی یک زبان باید از این توضیح استنتاج شوند، که ممکن است به زبان طبیعی یا قراردادی نوشته شود.
پیاده سازی منبع یا مدل. گاهی اوقات در زبان‌های مشخص شده(مثل: prolog,ANSI REXX).دستور و معناشناسی صریحاً در رفتار پیاده سازی مدل موجودند.


پیاده سازی

پیاده سازی یک زبان برنامه نویسی امکان اجرای آن برنامه را روی پیکربندی مشخصی از سخت‌افزار و نرم‌افزار را فراهم می‌کند. بطور وسیع، دو راه رسیدن به پیاده سازی زبان برنامه نویسی وجود دارد. کامپایل کردن و تفسیر کردن. بطور کلی با هر بک از ابن دو روش می‌توان یک زبان را پیاده سازی کرد.

خروجی یک کامپایلر ممکن است با سخت‌افزار و یا برنامه‌ای به نام مفسر اجرا شود. در برخی پیاده سازی‌ها که از مفسر استفاده می‌شود، مرز مشخصی بین کامپایل و تفسیر وجود ندارد. برای مثال، برخی پیاده سازی‌های زبان برنامه نویسی بیسیک کامپایل می‌کنند و سپس کد را خط به خط اجرا می‌کنند.

برنامه‌هایی که مستقیماً روی سخت‌افزار اجرا می‌شوند چندین برابر سریعتر از برنامه‌هایی که با کمک نرم‌افزار اجرا می‌شوند، انجام می‌شوند.

یک تکنیک برای بهبود عملکرد برنامه‌های تفسیر شده کامپایل در لحظه آن است. در این روش ماشین مجازی، دقیقاً قبل از اجرا، بلوک‌های کدهای بایتی که قرار است استفاده شوند را برای اجرای مستقیم روی سخت‌افزار ترجمه می‌کند.



تاریخچه
پیشرفت‌های اولیه

اولین زبان برنامه نویسی به قبل از رایانه‌های مدرن باز می‌گردد. قرن ۱۹ دستگاه‌های نساجی و متون نوازنده پیانو قابل برنامه نویسی داشت که امروزه به عنوان مثال‌هایی از زبان‌های برنامه نویسی با حوزه مشخص شناخته می‌شوند. با شروع قرن بیستم، پانچ کارت‌ها داده را کد گذاری کردند و پردازش مکانیکی را هدایت کردند. در دهه ۱۹۳۰ و ۱۹۴۰، صورت گرایی حساب لاندای آلونزو چرچ و ماشین تورینگ آلن تورینگ مفاهیم ریاضی بیان الگوریتم‌ها را فراهم کردند؛ حساب لاندا همچنان در طراحی زبان موثر است.

در دهه ۴۰، اولین رایانه‌های دیجیتال که توسط برق تغذیه می‌شدند ایجاد شدند. اولین زبان برنامه نویسی سطح بالا طراحی شده برای کامپیوتر پلانکالکول بود، که بین سال‌های ۱۹۴۵ و ۱۹۴۳ توسط کنراد زوس برای ز۳ آلمان طراحی شد.

کامپیوترهای اوایل ۱۹۵۰، بطور خاص ÜNIVAC ۱ و IBM ۷۰۱ از برنامه‌های زبان ماشین استفاده می‌کردند. برنامه نویسی زبان ماشین نسل اول توسط نسل دومی که زبان اسمبلی نامیده می‌شوند جایگزین شد. در سال‌های بعد دهه ۵۰، زبان برنامه نویسی اسمبلی، که برای استفاده از دستورات ماکرو تکامل یافته بود، توسط سه زبان برنامه نویسی سطح بالا دیگر: FORTRAN,LISP , COBOL مورد استفاده قرار گرفت. نسخه‌های به روز شده این برنامه‌ها همچنان مورد استفاده قرار می‌گیرند، و هر کدام قویا توسعه زبان‌های بعد را تحت تاثیر قرار دادند. در پایان دهه ۵۰ زبان algol ۶۰ معرفی شد، و بسیاری از زبان‌های برنامه نویسی بعد، با ملاحظه بسیار، از نسل algol هستند. قالب و استفاده از زبان‌های برنامه نویسی به شدت متاثر از محدودیت‌های رابط بودند.



پالایش

دوره دهه ۶۰ تا اواخر دهه ۷۰ گسترش مثال‌های عمده زبان پرکاربرد امروز را به همراه داشت. با این حال بسیاری از جنبه‌های آن بهینه سازی ایده‌های اولیه نسل سوم زبان برنامه نویسی بود:

APL برنامه نویسی آرایه‌ای را معرفی کرد و برنامه نویسی کاربردی را تحت تاثیر قرار داد.
PL/i(NPL) دراوایل دهه ۶۰ طراحی شده بود تا ایده‌های خوب فورترن و کوبول را بهم پیوند دهد.
در دهه ۶۰، Simula اولین زبانی بود که برنامه نویسی شئ گرا را پشتیبانی می‌کرد، در اواسط دهه۷۰. Smalltalk به دنبال آن به

عنوان اولین زبان کاملاً شئ گرا معرفی شد.

C بین سال‌های ۱۹۶۹ تا ۱۹۷۳ به عنوان زبان برنامه نویسی سیستمی طراحی شد و همچنان محبوب است.
Prolog، طراحی شده در ۱۹۷۲، اولین زبان برنامه نویسی منطقی بود.
در ۱۹۷۸ ML سیستم نوع چند ریخت روی لیسپ ایجاد کرد، و در زبان‌های برنامه نویسی کاربردی ایستا نوع گذاری شده پیشگام شد.

هر یک از این زبان‌ها یک خانواده بزرگ از وارثین از خود به جای گذاشت، و مدرنترین زبان‌ها از تبار حداقل یکی از زبان‌های فوق به شمار می‌آیند.

دهه‌های ۶۰ و ۷۰ مناقشات بسیاری روی برنامه نویسی ساخت یافته به خود دیدند، و اینکه آیا زبان‌های برنامه نویسی باید طوری طراحی شوند که آنها را پشتیبانی کنند.

"ادسگر دیکسترا" در نامه‌ای معروف در ۱۹۶۸ که در ارتباطات ACM منتشر شد، استدلال کرد که دستورgoto باید از تمام زبان‌های سطح بالا حذف شود.

در دهه‌های ۶۰ و ۷۰ توسعهٔ تکنیک‌هایی صورت گرفت که اثر یک برنامه را کاهش می‌داد و در عین حال بهره وری برنامه نویس و کاربر را بهبود بخشید. دسته کارت برای ۴GL اولیه بسیار کوچکتر از برنامهٔ هم سطح بود که با ۳GL deck نوشته شده بود.




یکپارچگی و رشد

دهه ۸۰ سال‌های یکپارچگی نسبی بود. C++ برنامه نویسی شئ گرا و برنامه نویسی سیستمی را ترکیب کرده بود. ایالات متحده ایدا(زبان برنامه نویسی سیستمی که بیشتر برای استفاده توسط پیمان کاران دفاعی بود) را استاندارد سازی کرد. در ژاپن و جاهای دیگر، هزینه‌های گزافی صرف تحقیق در مورد زبان نسل پنجم می‌شد که دارای ساختارهای برنامه نویسی منطقی بود. انجمن زبان کاربردی به سمت استانداردسازی ML و Lisp حرکت کرد. به جای ایجاد مثال‌های جدید، تمام این تلاش‌ها ایده‌هایی که در دهه‌های قبل حلق شده بودند را بهتر کرد.

یک گرایش مهم در طراحی زبان در دهه ۸۰ تمرکز بیشتر روی برنامه نویسی برای سیستم‌های بزرگ از طریق مدول‌ها، و یا واحدهای کدهای سازمانی بزرگ مقیاس بود. مدول-۲، ایدا. و ML همگی سیستم‌های مدولی برجسته‌ای را در دهه ۸۰ توسعه دادند. با وجود اینکه زبان‌های دیگر، مثل PL/i، پشتیبانی بسیار خوبی برای برنامه نویسی مدولی داشتند. سیستم‌های مدولی غالباً با ساختارهای برنامه نویسی عام همراه شده‌اند.

رشد سریع اینترنت در میانه دهه ۹۰ فرصت‌های ایجاد زبان‌های جدید را فراهم کرد. Perl، در اصل یک ابزار نوشتن یونیکس بود که اولین بار در سال ۱۹۸۷ منتشر شد، در وب‌گاه‌های دینامیک متداول شد. جاوا برای برنامه نویسی جنب سروری مورد استفاده قرار گرفت. این توسعه‌ها اساساً نو نبودند، بلکه بیشتر بهینه سازی شده زبان و مثال‌های موجود بودند، و بیشتر بر اساس خانواده زبان برنامه نویسی C بودند. پیشرفت زبان برنامه نویسی همچنان ادامه پیدا می‌کند، هم در تحقیقات و هم در صنعت. جهت‌های فعلی شامل امنیت و وارسی قابلیت اعتماد است، گونه‌های جدید مدولی(mixin، نماینده‌ها، جنبه‌ها) و تجمع پایگاه داده.

۴GLها نمونه‌ای از زبان‌هایی هستند که محدوده استفاده آنها مشخص است، مثل SQL. که به جای اینکه داده‌های اسکالر را برگردانند، مجموعه‌هایی را تغییر داده و بر می‌گردانند که برای اکثر زبان‌ها متعارفند. Perl برای مثال، با "مدرک اینجا" خود می‌تواند چندین برنامه ۴GL را نگه دارد، مانند چند برنامه جاوا سکریبت، در قسمتی از کد پرل خود و برای پشتیبانی از چندین زبان برنامه نویسی با تناسب متغیر در "مدرک اینجا" استفاده کند.




سنجش استفاده از زبان

مشکل است که مشخص کنیم کدام زبان برنامه نویسی بیشتر مورد استفاده‌است، و اینکه کاربرد چه معنی می‌دهد با توجه به زمینه تغییر می‌کند. یک زبان ممکن است زمان بیشتری از برنامه نویس بگیرد، زبان دیگر ممکن است خطوط بیشتری داشته باشد، و دیگری ممکن است زمان بیشتری از پردازنده را مصرف کند. برخی زبان‌ها برای کاربردهای خاص بسیار محبوبند. برای مثال: کوبول همچنان در مراکزداده متحد، غالباً روی کامپیوترهای بزرگ توانا است؛ fortran در مهندسی برنامه‌های کاربردی، C در برنامه‌های تعبیه شده و سیستم‌های عامل؛ و بقیه برنامه‌ها معمولاً برای نوشتن انواع دیگر برنامه‌ها کاربرد دارند. روش‌های مختلفی برای سنجش محبوبیت زبان‌ها، هر یک متناسب یا یک ویژگی محوری متفاوت پیشنهاد شده‌است:

شمارش تعداد تبلیغات شغلی که از آن زبان نام می‌برند.
تعداد کتاب‌های آموزشی و شرح دهندهٔ آن زبان که فروش رفته‌است.
تخمین تعداد خطوطی که در آن زبان نوشته شده اند- که ممکن است زبان‌هایی را که در جستجوها کمتر پیدا می‌شوند دست کم گرفته شوند.
شمارش ارجاع‌های زبان(برای مثال، به اسم زبان) در موتورهای جستجوهای اینترنت.

طبقه بندی‌ها هیچ برنامه غالبی برای دسته بندی زبان‌های برنامه نویسی وجود ندارد. یک زبان مشخص معمولاً یک زبان اجدادی ندارد. زبان‌ها معمولاً با ترکیب المان‌های چند زبان پیشینه بوجود می‌آیند که هربار ایده‌های جدید درگردشند. ایده‌هایی که در یک زبان ایجاد می‌شوند در یک خانواده از زبان‌های مرتبط پخش می‌شوند، و سپس از بین خلاهای بین خانواده‌ها منتقل شده و در خانواده‌های دیگر ظاهر می‌شوند.

این حقیقت که این دسته بندی ممکن است در راستای محورهای مختلف انجام شوند، این وظیفه را پیچیده تر می‌کند؛ برای مثال، جاوا هم یک زبان شیءگرا(چون به برنامه نویسی شیءگرا تشویق می‌کند) و زبان همزمان(چون ساختارهای داخلی برای اجرای چندین جریان موازی دارد) است. پایتون یک زبان اسکریپتی شیءگراست.

در نگاه کلی، زبان‌های برنامه نویسی به مثال‌های برنامه نویسی و یک دسته بندی بر اساس محدوده استفاده تقسیم می‌شوند. مثال‌ها شامل برنامه نویسی رویه‌ای، برنامه نویسی شیءگرا، برنامه نویسی کاربردی، وبرنامه نویسی منطقی؛ برخی زبان‌ها ترکیب چند مثالند. یک زبان اسمبلی مثالی از یک مدل مستقیم متضمن معماری ماشین نیست. با توجه به هدف، زبان‌های برنامه نویسی ممکن است همه منظوره باشند، زبان‌های برنامه نویسی سیستمی، زبان‌های اسکریپتی، زبان‌های محدوده مشخص، زبان‌های همزمان/ گسترده(و یا ترکیب اینها). برخی زبان‌های همه منظوره تا حد زیادی برای اهداف آموزشی طراحی شده‌اند.

یک زبان برنامه نویسی ممکن است با فاکتورهای غیر مرتبط به مثال‌های برنامه نویسی دسته بندی شود. برای مثال، غالب زبان‌های برنامه نویسی کلمات کلیدی زبان انگلیسی را استفاده می‌کنند، در حالیکه تعداد کمی این کار را نمی‌کنند. سایر زبان‌ها ممکن است براساس داخلی بودن یا نبودن دسته بندی شوند.
ساعت : 1:49 am | نویسنده : admin | طراحی وب امیر | مطلب قبلی
طراحی وب امیر | next page | next page