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

• سند چشم‌انداز (Vision)

سند چشم‌انداز (Vision) به منظور توصیف اهدافِ مجموعه‌ فعالیت‌های توسعه‌ی یک سیستم نرم‌افزاری از منظر ذینفعان آن تهیه می‌شود. در این سند، چرایی‌ها (ضرورت‌ها) و چیستی‌های مرتبط با پروژه، و نیز ملاحظات کلیدی آن که باید به تأیید ذینفعان پروژه برسد، بیان می‌شود.

ساختار کلی این سند به صورت زیر است:

• کلیات سند
• موقعیت (Positioning) محصول/راهکار
• توصیفِ ذینفعان و کاربران
• مروری بر راهکار (محصول)
• ویژگی‌های راهکار (محصول)
• محدودیت‌ها
• حیطه‌ها و محدوده‌های کیفی
• اولویت‌ها و پیش‌‌زمینه‌ها
• سایر نیازمندی‌های راهکار (محصول)
• نیازمندی‌های مستندسازی

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

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

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

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

اما به واسطه‌ی تغییرات بسیار سریع و غافل‌گیرکننده‌ی فناوری‌های نوین اطلاعاتی و ارتباطی و به‌طور خاصْ نرم‌افزار، و به موازاتِ آن، تغییر نیازها، خواسته‌ها، و انتظارات استفاده‌کنندگان از نرم‌افزار و قابلیت‌های آن، طراحی و تولید نرم‌افزار، بسیار پیچیده است. عوامل دیگری مانند رقابت شدید، کمبود نیروی متخصص و حرفه‌ای، عدمِ دسترسی به دانش و تجربه‌‌ی موفق دیگران، لزوم تولید سریع، لزوم تولید مقرون به ‌صرفه، نیاز روز افزون به همکاری میان رشته‌های مختلف، و مهم‌تر از همه‌، عدمِ استفاده‌ی مناسب از اصول و مبانی مهندسی در طراحی تولید نرم‌افزار، این صنعت را با چالش‌های بسیاری روبرو نموده است.
سرانجام برای اولین بار، در سال ۱۹۶۸ و در یک کنفرانس که توسط ناتو در کشور آلمان برگزار شده بود، بر لزوم مهندسیِ این دستاورد جدیدِ بشر، یعنی نرم‌افزار، تأکید شد. از آن زمان به بعد، با مطرح‌شدن روزافزون مفهوم  مهندسی نرم افزار و در نتیجه با گسترش تکنیک‌های مهندسی، ابزارها، و دانش و تجربه، صنعت نرم‌افزار به یکی از صنایع برتر جهانی تبدیل شده است.

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

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

1. مرحله‌ی مهندسی، شامل فازهایاستارتاپ (آغاز) و معماری
2. مرحله‌ی فرآوری، شامل فازهای ساخت و انتقال

• برخی تصورات اشتباه

باوجودی‌که چهار فاز فرایند توسعه‌ی نرم‌افزار (استارتاپ، معماری، ساخت، و انتقال) به صورت متوالی و پشت سرِ هم اجرا می‌شوند، نباید تصور کرد که این چرخه همان رویکرد سنتی آبشاری است. چارچوب فرایند توسعه‌ی نرم‌افزار اساساً رویکردی است تکرارشونده (iterative) و مبتنی بر ریسک (risk-driven).

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

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

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

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

برگرفته از : unifiedprocess