آموزش مهندسی نرم افزار

کتاب مرجع درس مهندسی نرم افزار:

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

سرفصل‌های درس مهندسی نرم افزار:

سرفصل‌های آموزش مهندسی نرم افزار شامل فصول مفاهیم اولیه مهندسی نرم افزار، مدل های فرآیند تولید نرم افزار، مدل تحلیل ساخت یافته، مفاهیم طراحی ساخت یافته، مدل طراحی ساخت یافته، مفاهیم شیء گرایی، مدل تحلیل و طراحی شیء گرایی بر اساس UML، تست و استقرار نرم افزار، مدیریت پروژه های نرم افزاری، متدولوژی RUP، متدولوژی چابک و برنامه‌های تحت وب است. به صورت زیر:

فصل اول: مفاهیم اولیه مهندسی نرم‌افزار

فصل دوم: مدل‌های فرآیند تولید نرم‌افزار

فصل سوم: مدل تحلیل ساخت‌یافته

فصل چهارم: مفاهیم طراحی ساخت‌یافته

فصل پنجم: مدل طراحی ساخت‌یافته

فصل ششم: مفاهیم شیء گرایی

فصل هفتم: مدل تحلیل و طراحی شیء‌گرایی بر اساس UML

فصل هشتم: تست و استقرار نرم‌افزار

فصل نهم: مدیریت پروژه‌های نرم‌افزاری

فصل دهم: متدولوژی RUP

فصل یازدهم: متدولوژی چابک

تغییرات و مباحث جدید درس مهندسی نرم افزار:

1- مدل‌های فرآیند تولید نرم‌افزار

• V Model
• Risk- Driven (ریسک- رانه)

2 – اصول S.O.L.I.D

• SRP (اصل تک مسئولیتی)
  Single Responsibility Principle

• OCP (اصل باز بسته)
  Open / Closed Principle

• LSP (اصل جایگزینی لیسکوف)
  Liskov Substitution Principle

• ISP (اصل جداسازی اینترفیس‌ها)
  Interface Segregation Principle

• DIP (اصل وارونگی وابستگی)
  Dependency Inversion Principle

3 – کلاس طراحی خوش – تعریف

• Well Formed

4 – قاعده سه‌بخشی

• Context (حوزه)
•  problem (مسئله)
•  Solution (راه حل)

5 – طراحی مبتنی بر وب

• Navigation (مسیریابی)

6 – متدولوژی‌های چابک

• XP
• Scrum
• Kanban
• FDD

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

توجه: به کل سرفصل‌های فوق برای کنکور ارشد فناوری اطلاعات باید مسلط باشید.

جزوه کنکوری درس مهندسی نرم افزار:

بهترین جزوه نتیجه‌گرا و امن این درس جزوه درس و نکته و تست مهندسی نرم افزار استاد خلیلی‌فر است.

کتاب کنکوری درس مهندسی نرم افزار:

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

کلاس آنلاین آموزش مهندسی نرم افزار:

بهترین کلاس آنلاین نتیجه‌گرا و امن این درس کلاس آنلاین مهندسی نرم افزار گروه بابان استاد ارسطو خلیلی فر است.

کلاس آفلاین آموزش مهندسی نرم افزار:

بهترین کلاس آفلاین نتیجه‌گرا و امن این درس کلاس آفلاین مهندسی نرم افزار گروه بابان استاد ارسطو خلیلی فر است.

مفاهیم اولیه مهندسی نرم‌افزار

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

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

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

نرم‌افزار

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

ویژگی‌های نرم‌افزار

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

1- نرم‌افزار توسعه می‌یابد

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

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

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

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

2- نرم‌افزار فرسوده نمی‌شود

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

اما نرم‌افزار در معرض عوامل محیطی که سخت‌افزار را فرسوده می‌کند، نمی‌باشد. بنابراین از نظر تئوری منحنی عدم موفقیت در مورد نرم‌افزار شکل یک منحنی ایده‌آل را می‌گیرد که در شکل زیر نشان داده شده است.

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

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

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

3- مونتاژ قطعات

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

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

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

بحران نرم‌افزاری

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

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

در همان نسل‌های ابتدایی تکامل نرم‌افزار تولید و فروش کامپیوترهای شخصی به دلیل تقاضای فراوان از سوی مصرف‌کنندگان و خریداران به شدت افزایش یافت. بنابراین نیاز به برنامه‌های مختلف کامپیوتری به شدت احساس گردید و این امر سبب تولید فراوان نرم‌افزار شد بدون آنکه قانونی، عمل نظارت بر تولید نرم‌افزار را داشته باشد و همین مسئله نارضایتی‌های زیادی را برای مصرف‌کنندگان این نرم‌افزارها به بار آورد، این مشکلات و چالش‌ها به قدری جدی و پرهزینه ‌بود که از آن به «بحران نرم‌افزار» یاد می‌شد. این بحران در سال‌های 1960 تا 1970 به شکل پیچیده‌ای به اوج خود رسید و درست در همان سال‌ها بود که بحث «مهندسی نرم‌افزار» به شکل جدی‌تر مطرح شد.

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

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

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

خصوصیات پروژه‌های موفق

بر اساس آمارهای معتبری که توسط مؤسساتی مانند International Data Corporation و Standish Group و در پی بررسی هزاران پروژه‌ی نرم‌افزاری که در ابعاد و زمینه‌های مختلف تهیه شده است، درصد زیادی از پروژه‌های نرم‌افزاری در دنیا با شکست و عدم موفقیت مواجه می‌شوند.

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

• بازه‌ی زمانی از قبل برنامه‌ریزی شده (بازه‌ی زمانی مشخص)
• بودجه‌ای از قبل پیش‌بینی شده و با صرف کمترین هزینه (مقرون به صرفه)
• دقیقاً مطابق با نیازمندی‌های واقعی کاربران (کیفیت مطلوب)

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

مهندسی نرم‌افزار

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

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

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

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

به قول حضرت مولوی

هرکسی را بهرکاری ساختند          میل آن را در دلش انداختند

مهندس نرم‌افزار

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

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

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

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

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

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

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

مؤلفه‌های نرم‌افزار

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

و شامل مؤلفه‌های زیر می‌باشد:

1- ساختار داده‌ای: محل نگهداری داده‌های محیط عملیاتی به شکل متغیرها و جداول.

2- ‏عملکرد: دستورات یا کدهای قابل اجرا که باعث انجام وظایف مورد نظر می‌شود که به برنامه کاربردی موسوم است.

3- ‏مستندات: شامل توصیف مدل‌های تحلیل و طراحی نزد سازنده و راهنمای کاربر نزد کاربران نهایی و مشتری.

توجه: هر یک از این مؤلفه‌ها شامل یک پیکربندی است که بر اساس اصول مهندسی نرم‌افزار (فرآیندها، روش‌ها و ابزارها) ایجاد می‌گردد.

انواع نرم‌افزارها

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

‏در یک دسته‌بندی کلی برای نرم‌افزارهای موجود، می‌توان آنها را به دو گروه اصلی زیر تقسیم نمود:

نرم‌افزارهای کاربردی

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

نرم‌افزارهای سیستمی

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

در یک دسته‌بندی دقیق‌تر برای نرم‌افزارهای موجود، می‌توان آنها را به گروه‌های زیر تقسیم نمود:

‏نرم‌افزارهای بی‌درنگ

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

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

نرم‌افزارهای مدیریت پایگاه داده

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

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

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

نرم‌افزارهای نهفته (توکار)

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

نرم‌افزارهای خط تولیدی

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

نرم‌افزارهای مبتنی بر وب

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

نرم‌افزارهای هوش مصنوعی

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

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

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

لایه‌های مهندسی نرم‌افزار

مهندسی نرم افزار از چهار لایه ابزارها، روش‌ها، فرآیندها و کیفیت ایجاد شده است، که نتیجه استفاده درست از فرآیندها، روش‌ها و ابزارها می‌شود کیفیت. بنابراین ‏مهندسی نرم‌افزار یک فرآیند لایه‌ای است.

در شکل زیر، چهار لایه نشان داده شده است:

کیفیت

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

‏برای ­مثال کیفیت خانه برای برآورده ساختن آرامش و نیازهای مشتری، مهم است. اما شیوه‌های رسیدن به این مهم در شهرهای شمالی و جنوبی شباهت‌ها و تفاوت‌هایی دارد. به طور مثال در شهرهای شمالی بارندگی به وفور وجود دارد، پس روش‌ها و ابزارهای ساختمانی باید به گونه‌ای انتخاب شوند که در برابر بارندگی مقاوم باشند. مثل روش سقف شیروانی با استفاده از ابزار سفال!

‏فرآیندها (فرآیند تولید نرم‌افزار)

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

‏همانطور که ملاحظه می‌نمایید، ورودی این فرآیند، نیاز یا خواسته‌های مشتری و خروجی آن، یک محصول نرم‌افزاری است. یک فرآیند تولید در یک پروژه به ما می‌گوید که برای دستیابی به هدف مطلوب که همان تولید یک فرآورده‌ی نرم‌افزاری با کیفیت مطلوب است، چه کسی Who، چه کاری را What، چه موقع When و چگونه How باید انجام دهد، در واقع، بدون داشتن تعریف مشترکی از فرآیند تولید نرم‌افزار، هماهنگی انجام کار تیمی در یک پروژه‌ی نرم‌افزاری، امکان‌پذیر نخواهد بود.

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

روش‌ها

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

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

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

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

ابزارها

ابزارهای فنی برای ساخت نرم‌افزار را «ابزار» می‌گوییم و به دو شکل ابزار ساخت‌یافته و ابزار شیءگرا می‌باشند. شکل زیر ابزارهای ساخت‌یافته را در روش ساخت‌یافته نمایش می‌دهد:

توجه: ابزارهای شیءگرا، در فصل مربوط به مباحث شیءگرایی معرفی خواهند شد. مانند ابزار UML که سرواژه عبارت Unified Modeling Language است و به معنی زبان مدل­سازی یکپارچه می­باشد که جهت مدل‌سازی متدولوژی شیءگراء مورد استفاده قرار می­گیرد.

ابزارهای کاغذی (Tool) : به معنی استفاده از ابزار به صورت دستی و نقشی بر روی کاغذ بدون استفاده از کامپیوتر مانند رسم نمودار ER بدون کامپیوتر یا رسم نمودارهای UML بدون کامپیوتر یا نوشتن کدهای برنامه‌نویسی بر روی کاغذ بدون کامپیوتر.

ابزارهای کامپیوتری (Computer-Aided Software Engineering Tool) : (CASE TOOL)

به معنی استفاده از ابزار به کمک کامپیوتر، مانند رسم نمودار ER به کمک کامپیوتر توسط نرم‌افزار ویزیو یا رسم نمودارهای UML به ‏کمک کامپیوتر توسط نرم‌افزار رشنال رُز یا نوشتن کدهای برنامه‌نویسی به کمک کامپیوتر توسط کامپایلرها.

توجه: ابزارهای کامپیوتری (CASE TOOL) می‌توانند، در کلیه مراحل فرآیند تولید نرم‌افزار (ارتباطات، برنامه‌ریزی، مدل‌سازی (تحلیل و طراحی)، ساخت (پیاده‌سازی و تست) و استقرار) مورد استفاده قرار گیرند.

تکنیک‌های نسل چهارم (4GT : Fourth Generation Techniques)

تکنیک‌های نسل چهارم، دسته‌ای از ابزارهای CASE هستند که در فعالیت پیاده‌سازی، کد برنامه را به صورت خودکار تولید می‌نمایند. البته شرط لازم برای این کار، توصیف مشخصات نرم‌افزار در یک سطح انتزاعی بالا در فعالیت مدل‌سازی (نمایش نرم‌افزار توسط اشکال و علائم گرافیکی) است. مانند تولید خودکار کدهای HTML توسط نرم‌افزار Dreamweaver یا FrontPage، تولید کدهای برنامه توسط نرم‌افزار رشنال رُز که نمودارهای آن در سطح انتزاعی بالا توسط نمودار­های UML ایجاد شده است.

متدولوژی

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

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

توجه: اساس به وجود آمدن متدولوژی شیءگرا به وجود آمدن نیازهای جدید بوده که توسط متدولوژی ساخت‌یافته قابل پوشش دادن نبوده‌اند. متدولوژی شیءگرا برخی از نیازمندی‌های جدید را پوشش داده است و این طور نبوده‌­است که استفاده از متدولوژی ساخت‌یافته را منسوخ کند.

‏متدولوژی ساخت‌یافته 

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

در متدولوژی ساخت‌یافته، در اولین مرحله مدل‌سازی (مدل تحلیل)، سیستم به دو وجه «داده» ‏و «عملکرد» ‏تفکیک می‌شود. سپس طی روندی سلسله مراتبی و مطابق با روش بالا به پایین، هر یک از این وجوه خود به مؤلفه‌های فرعی تجزیه می‌شوند. این روند تا به جایی ادامه می‌یابد که جزئیات توابع برنامه جهت پیاده‌سازی مشخص شوند.

توجه: ‏متدولوژی SSADM متداول‌ترین نمونه از متدولوژی ساخت‌یافته براساس روش ساخت‌یافته، مدل فرآیند تولید آبشاری و ابزارهای ساخت‌یافته می‌باشد. و بر دو نوع داده‌گرا (جدولی) مانند نرم‌افزار حقوق و دستمزد که داده‌ها درون جداول ذخیره می‌شوند و تابع‌گرا (متغیری) مانند نرم‌افزار ماشین‌حساب که داده‌ها درون متغیر‌ها ذخیره می‌شوند، می‌باشد.

توجه: ‏نسبت نمونه متدولوژی ساخت­یافته SSADM به متدولوژی ساخت­‌یافته، مثل نسبت سیستم­‌عامل ویندوز سنتی به مفاهیم سنتی سیستم‌­عامل است.

‏متدولوژی شیء‌گرا 

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

در ‏متدولوژی شیءگرا، در اولین مرحله‌ی مدل‌سازی (مدل تحلیل) سیستم در قالب کلاس‌ها (شامل داده (صفت) و عملکرد (متد)) نشان داده می‌شود. سپس طی روندی سلسله مراتبی و مطابق با روش بالا به پایین، کلاس‌ها با جزئیات بیشتری مشخص می‌شوند. این روند تا به جایی ادامه می‌یابد که  جزئیات کلاس‌ها‌ی برنامه جهت پیاده‌سازی مشخص ‌شوند.

توجه: ‏متدولوژی RUP متداول‌ترین نمونه از متدولوژی شیءگرا براساس روش شیءگرا (مبتنی بر مفاهیم کلاس، وراثت و چندریختی)، مدل فرآیند مبتنی بر مؤلفه‌ی شیءگرا با رویکرد تکرار و تکامل و ابزارهای شیءگرا (مثل ابزار مدل‌سازی UML و زبان برنامه‌نویسی C++) می‌باشد.

توجه: ‏نسبت نمونه متدولوژی شیء­گرای RUP به متدولوژی شیء­گرا، مثل نسبت سیستم عامل ویندوز مدرن به مفاهیم مدرن سیستم عامل است.

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

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

در ادامه آموزش مهندسی نرم افزار فعالیت‌های چارچوبی فرآیند تولید نرم‌افزار براساس متدولوژی ساخت‌یافته بیان خواهد شد:

1- ارتباطات (مهندسی نیازمندی‌های مشتری یا مهندسی خواسته­‌های مشتری) 

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

فرآیند تهیه لیست نیازمندی­‌های مشتری

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

روش‌های تهیه لیست نیازمندی­های مشتری

روش‌های تشخیص برای تهیه لیست نیازمندی‌­های مشتری را «روش­‌های تهیه لیست نیازمندی­‌های مشتری» می­‌گوییم، یکی از روش‌­های پرکاربرد روشی موسوم به «روش QFD» می‌باشد.

توجه: QFD سرواژه عبارت Quality Function Deployment و به معنی استقرار عملکرد کیفیت می­‌باشد.

توجه: روش QFD جلوتر شرح داده خواهد شد.

ابزار­های تهیه لیست نیازمندی­‌های مشتری

ابزارهای تشخیص برای تهیه لیست نیازمندی‌­های مشتری را «ابزارهای تهیه لیست نیازمندی‌های مشتری» می‌گوییم و به پنج شکل «گفتگو»، «مشاهده»، «پرسش‌نامه»، «مکانیزم نمونه‌سازی دورانداختنی» و «مکانیزم نمونه‌سازی تکاملی» می‌باشد.

توجه: مکانیزم نمونه‌سازی دورانداختنی و تکاملی جلوتر شرح داده می‌شود.

توجه: فعالیت ارتباطات از طریق ارتباط با مشتری توسط ارتباط‌گر و ابزارها و روش‌های مطرح شده انجام می‌گردد.

مراحل فرآیند تهیه لیست نیازمندی‌های مشتری

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

در ادامه مراحل فرآیند تهیه لیست نیازمندی­‌های مشتری بیان خواهد شد:

1- درک (شناخت اولیه نیازمندی­‌ها)

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

2- استخراج (شناخت بیشتر نیازمندی‌­ها)

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

توجه: توسط استفاده از روش QFD می­‌توان به شناخت خواسته­‌هایی از مشتری بپردازیم که برای مشتری ارزشمندتر است. QFD سه نوع خواسته را مشخص می­‌کند:

خواسته‌­های عادی: به خواسته‌­هایی که مشتری بیان می‌­کند و انتظار هم دارد که سازنده این خواسته‌­ها را برآورده سازد، خواسته‌­های عادی گفته می‌­شود که در صورت برآورده‌سازی این خواسته­‌ها توسط سازنده، مشتری راضی خواهد بود.

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

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

توجه: برآورده‌سازی «خواسته‌های عادی» و «خواسته‌های مورد انتظار» از سوی سازنده اجباری و معیار سنجش مشتری است و برآورده‌سازی «خواسته‌های هیجان‌انگیز» از سوی سازنده، اختیاری و معیار سنجش مشتری نیست ولی اگر از سوی سازنده این دسته از خواسته‌ها برآورده گردد، مشتری هیجان زده خواهد شد. راز موفقیت «استیو جابز (Steve Jobs)» رهبر فقید کمپانی اپل برآورده‌سازی «خواسته‌های هیجان‌انگیز» علاوه بر برآورده‌سازی «خواسته‌های عادی» و «خواسته‌های مورد انتظار» بود. موفقیت یعنی توجه کردن به جزئیات. «استیو جابز»

3- تشریح نیازمندی­‌های شناخته شده

در مرحله تشریح نیازمندی­‌های شناخته‌­شده، نیازمندی­‌هایی که در دو مرحله شناخت اولیه نیازمندی‌­ها و شناخت بیشتر نیازمندی­‌ها کشف شده­‌اند، با بیان ذکر جزئیات بیشتر، تشریح می‌شوند.

4- مذاکره

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

5- تعیین مشخصات

پس از توافقات لازم بر سر نهایی‌­شدن نیازمندی‌­های شناخته­‌شده در مرحله مذاکره، در ادامه و در مرحله تعیین مشخصات، مشخصات سیستمی که باید ایجاد گردد، تحت عنوان لیست نیازمندی‌های مشتری نوشته می­‌شود. همچنین این لیست می‌­تواند به صورت گرافیکی توسط نمودار مورد کاربرد یا use case diagram مدل­‌سازی شود.

توجه: نمودار مورد کاربرد یا use case diagram مربوط به مفاهیم شیء­گرایی است.

6- اعتبارسنجی نیازمندی‌­ها

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

7- مدیریت نیازمندی‌­ها

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

انواع نیازمندی‌ها

1- وظیفه‌مندی (Functional) (کارکردی، عملکردی)

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

‏مانند نیازمندی‌های مربوط به محاسبه‌ی فاکتوریل یک عدد و یا اجرای تابع فیبوناچی در یک نرم‌افزار و یا نیازمندی‌های مربوط به یک نرم‌افزار حقوق و دستمزد.

توجه: نیازمندی‌های وظیفه‌مندی، موسوم به نیازها یا «خواسته‌های عادی» است.

2- غیروظیفه‌مندی (Non Functional) (غیرکارکردی، غیر عملکردی)

‏نیازمندی‌های غیروظیفه‌مندی، نیازمندی‌های کیفی و نه الزاماً قابل اندازه‌گیری هستند که به بیان کیفیت مورد انتظار از نیازمندی‌های وظیفه‌مندی و همچنین محدودیت‌هایی نظیر محدودیت‌های زمانی، مالی و استانداردها می‌پردازند. برخی از انواع نیازمندی‌های غیروظیفه‌مندی عبارتند از:

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

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

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

توجه: محصول نرم­‌افزاری باید برآورده کننده نیازمندی‌­های هم وظیفه­‌مندی و هم غیر‌وظیفه‌مندی مشتری باشد. محصول نرم‌افزاری که نیازمندی‌های وظیفه‌مندی را برآورده می‌کند، ولی برآورنده نیازمندی‌های غیروظیفه‌مندی نباشد، معمولاً با نارضایتی مشتریان همراه می‌شود.

‏توجه : انتخاب نوع الگوریتم براساس شرایط، حائز اهمیت می‌باشد.

توجه: نیازمندی‌های غیروظیفه‌مندی، موسوم به نیازمندی‌ها یا «خواسته‌های مورد انتظار» است.

2- برنامه‌ریزی

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

«هر تلاشی منجر به نتیجه‌ای مطلوب نمی‌گردد، بلکه این تلاشی مطلوب است که منجر به نتیجه‌ای مطلوب می‌گردد.»

‏لازمه‌ی تلاش مطلوب، برنامه‌ریزی است. برنامه‌ریزی می‌تواند اجرای هر کار پیچیده‌ای را ساده‌تر سازد. ‏هر کار مهندسی مستلزم برنامه‌ریزی می‌باشد. مهندسی نرم‌افزار نیز مانند هر فعالیت مهندسی دیگری، نیازمند برنامه‌ریزی است. فعالیت برنامه‌ریزی، برنامه‌ای را برای فعالیت‌های مختلف بخش‌های مختلف فرآیند تولید نرم‌افزار پایه‌ریزی می‌کند. این فعالیت، وظیفه‌های فنی که باید هدایت شوند، ریسک‌هایی که محتمل می‌شوند (مانند عدم شناسایی برخی نیازمندی‌ها، از دست دادن داده‌ها و مدیران)، منابع مورد نیاز، واحدهای کاری که باید ایجاد شوند و برنامه زمان‌بندی برای کارها را تشریح می‌کند. مدیریت، برنامه‌­ریزی را به مرحله‌­ی اجرا می­‌برد.

3- مدل‌سازی (تحلیل و طراحی)

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

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

مدل تحلیل

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

‏در مدل تحلیل به روش ساخت‌یافته دو وجه مدل تحلیل داده و مدل تحلیل عملکرد وجود دارد. مدل تحلیل داده شامل تحلیل موجودیت‌ها و تحلیل پرس و جوها می‌باشد. تحلیل موجودیت‌ها توسط ابزار مدل ER و تحلیل پرس و جوها توسط ابزار حساب رابطه‌ای مدل می‌شوند. مدل تحلیل عملکرد توسط ابزار DFD مدل می‌شود.

‏مدل طراحی

پس از مدل تحلیل، نوبت به مدل طراحی می‌رسد، ‏مدل طراحی به روش ساخت‌یافته شامل چهار بخش طراحی‌­داده، طراحی­‌معماری، طراحی­‌مؤلفه و طراحی­‌واسط می‌باشد. طراحی داده بر دو بخش طراحی جدول و طراحی پرس و جو می‌باشد. طراحی جدول از بخش طراحی داده، تحلیل موجودیت (ERD) از مدل تحلیل را به عنوان ورودی دریافت کرده و توسط مدل رابطه‌ای، طراحی جدول را انجام می‌دهد. طراحی پرس و جو از بخش طراحی داده، تحلیل پرس و جو از مدل تحلیل را به عنوان ورودی دریافت کرده و توسط جبر رابطه‌ای، طراحی پرس و جو را انجام می‌دهد.

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

طراحی معماری یا معماری نرم‌افزار، ساختار کلی نرم‌افزار و شیوه‌های یکپارچگی یک سیستم را بیان می‌کند. به عبارت دیگر، ساختار سلسله مراتبی مولفه‌های برنامه (توابع یا پیمانه‌ها)، شیوه تعامل مولفه‌ها با یکدیگر و ساختمان داده‌های مورد نیاز مولفه‌ها را نشان می‌دهد. معماری نرم‌افزار یک مدل قابل درک از چگونگی سازمان‌دهی سیستم است. در واقع نشان‌گر ساختمان داده‌ها و مؤلفه‌های برنامه‌ای است که برای ساختن یک سیستم کامپیوتری لازم است. به طور دقیق‌تر معماری نرم‌افزار شامل دو سطح از طراحی می‌باشد یعنی طراحی داده و طراحی معماری. در واقع این ساختار مانند یک نقشه ساختمان، مبنای ساخت نرم‌افزار قرار می‌گیرد.

توجه: در طراحي معماری، اسکلت، ساختار و چيدمان كلی مولفه­‌های (توابع) برنامه به این معنی که چه مولفه‌­ای (تابعی) چه مولفه­‌ای (تابعی) دیگر را صدا می‌­زند، بدون ذکر جزئیات داخلی مولفه‌­ها (توابع) مشخص می‌گردد (ساختار درختی برنامه بدون ذکر جزئیات مولفه‌­ها (توابع)). مانند اسكلت يك ساختمان كه گويای جايگاه مؤلفه‌های ساختمان است اما هنوز آجرچينی نشده است. (اسكلت يك ساختمان بدون آجرچينی).

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

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

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

‏‏توجه: در طراحی مؤلفه، اسکلت، ساختار و چيدمان كلی مولفه­‌های (توابع) برنامه به این معنی که چه مولفه‌­ای (تابعی) چه مولفه­‌ای (تابعی) دیگر را صدا می‌­زند، با ذکر جزئیات داخلی مولفه‌ها (توابع) مشخص می‌گردد (ساختار درختی برنامه با ذکر جزئیات مولفه­‌ها (توابع)). مانند اسكلت يك ساختمان كه گويای جايگاه مؤلفه‌های ساختمان است و آجر‌چينی هم شده است. (اسكلت يك ساختمان به همراه آجرچينی).

توجه: به طراحی مولفه، طراحی جزئی، طراحی تفصیلی و طراحی رویه‌ای نیز گفته می‌شود.

طراحي واسط يا همان واسط كاربر، ‌براساس ورودی‌ها و خروجی‌های مورد نياز كاربران نهايی به شكل نقشی بر روی كاغذ يا طرحی بر روی كامپيوتر ايجاد می‌گردد. مانند نحوه چيدمان منوها و فرم‌ها.

4- ‏ساخت (پیاده‌سازی و تست)

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

پیاده‌سازی پرس و جو از بخش پیاده‌سازی داده، طراحی پرس و جو از مدل طراحی را به عنوان ورودی دریافت کرده و توسط دستورات DML در SQL پیاده‌سازی پرس و جو را انجام می‌دهد. پیاده‌سازی عملکرد، طراحی مؤلفه از مدل طراحی را به عنوان ورودی دریافت کرده و توسط یک زبان برنامه‌نویسی (ساخت‌یافته یا شیءگرا) پیاده‌سازی عملکرد را انجام می‌دهد.

توجه: دقت­‌کنید که می‌توان مدل تحلیل و طراحی را به روش و ابزارهای ساخت‌یافته انجام ‏داد ولی فعالیت پیاده‌سازی را توسط یک زبان برنامه‌نویسی شیءگرا انجام داد و از امکانات شیءگرایی زبان استفاده نکرد، اما عکس این مطلب امکان‌پذیر نیست، یعنی نمی‌توان مدل تحلیل و طراحی را به روش شیءگرا انجام داد ولی فعالیت پیاده‌سازی را توسط یک زبان ساخت‌یافته انجام داد زیرا زبان ساخت‌یافته امکانات شیءگرایی (همچون کلاس، وراثت و چندریختی) را پشتیبانی نمی‌کند.

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

5- ‏استقرار

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

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

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

فعالیت‌های چتری فرآیند تولید نرم‌افزار

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

به قول حضرت حافظ

در بیابان‌گر به شوق کعبه خواهی زد قدم            سرزنش‌ها‌گر کند خار مغیلان غم مخور

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

انواع فعالیت‌های چتری

1- کنترل و پیگیری پروژه‌‌ی نرم‌افزاری

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

2- ‏مدیریت ریسک

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

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

3- تضمین کیفیت نرم‌افزار (SQA : Software Quality Assurance)

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

4- بازبینی‌های فنی (FTR : Formal Technical Review)

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

5- اندازه‌گیری

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

6- مدیریت پیکربندی نرم‌افزار (Software Confiquration Management)

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

7- مدیریت قابلیت استفاده مجدد

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

8- تولید و پیش تولید محصولات کاری

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

مدل‌های فرآیند تولید نرم‌افزار

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

‏مدل‌های فرآیند تولید نرم‌افزار سنتی (ساخت‌یافته)

مدل‌های فرآیند تولید نرم‌افزار سنتی بر دو دسته‌ی کلی غیرتکاملی سنتی و تکاملی سنتی هستند:

مدل‌های غیرتکاملی سنتی

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

1- مدل آبشاری (Waterfall model)

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

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

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

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

توجه: به مدل آبشاری، مدل خطی (Linear Model) و مدل ترتیبی (Sequential Model) نیز گفته می‌­شود.

معایب مدل آبشاری

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

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

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

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

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

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

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

مدل توسعه سریع

مدل RAD یا Rapid Application Development، شکل پُرسرعت مدل آبشاری می‌باشد، با این تفاوت که پروژه به بخش‌های مختلف تقسیم شده و هر بخش، توسط یک تیم، مطابق مدل آبشاری ایجاد می‌گردد و در پایان نتیجه‌ی تیم‌ها، برای خلق محصول نهایی ترکیب می‌گردد. مدل RAD، سرعت خود را مدیون بهره‌گیری از تکنیک بخش­‌بندی و موازی‌سازی بخش‌های مختلف پروژه است. چنانچه نیازمندی‌ها به خوبی شناسایی شده و دامنه‌ی پروژه کوچک باشد این مدل قادر است یک سیستم کاملاً عملیاتی را در مدت زمان بسیار کوتاه (مثلاً بین 60 تا 90 روز) تولید نماید.

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

ویژگی‌های مدل RAD

1- شرط لازم برای انجام پروژه‌های نرم‌افزاری توسط مدل RAD، قابلیت بخش‌بندی پروژه است.

2- از آنجا که در مدل RAD، هر بخش از مدل آبشاری استفاده می‌کند، پس بنا بر ویژگی‌های مدل آبشاری، باید تمامی نیازمندی‌های پروژه (لیست نیازمندی‌ها) در ابتدای پروژه مشخص باشد. در این صورت این مدل می‌تواند ظرف مدت بسیار کوتاهی (60 تا 90 روز) محصول نهایی را ایجاد نماید.

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

4- این مدل در پروژه‌هایی با ریسک‌های فنی بالا، به دلیل عدم امکان شناسایی نیازمندی‌های مشتری در ابتدای پروژه کارآمد نخواهد بود.

5- موفقیت مدل RAD، وابسته به تعامل مناسب سازنده و مشتری است و هر دو باید برای انجام سریع فعالیت‌ها با یکدیگر هماهنگ باشند تا بتوانند در موعد مقرر تولید نهایی را تحویل مشتری دهند. چون اگر یک قسمت از این پروژه انجام نشده باشد. تحویل پروژه میسر نیست، بنابراین مدیریت این مدل اهمیت فراوانی دارد.

مکانیزم نمونه‌سازی دورانداختنی

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

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

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

توجه: در ادامه مکانیزم نمونه‌سازی دورانداختنی را، به اختصار «نمونه‌سازی» در نظر خواهیم گرفت.

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

‏اما آیا نمی‌توان به آنها اشکال گرفت که چرا وقتی مطمئن نبودید که دقیقاً چه می‌خواهید و چه می‌خواهید بسازید با هم بر سر ساخت توافق کردید؟!

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

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

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

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

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

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

یادتان باشد در حال ‏ساخت نمونه برای مشاهده مشتری و شناسایی مابقی نیازمندی‌های او هستید، لیست نیازمندی‌های مشتری که دقیقاً مشخص شد و بعد به توافق نهایی هم رسیدید، نمونه‌های ساخت شده را دور بریزید، زیرا به هدفی که می‌خواستید رسیدید، نیازها مشخص شدند و دیگر به نمونه‌ها نیازی ندارید!

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

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

مدل نمونه‌سازی

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

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

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

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

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

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

معایب مدل نمونه‌سازی

1- ‏چون نمونه‌ای از نرم‌افزار بدون رعایت مسائل کیفی در اختیار مشتری قرار می‌گیرد و مشتری در ابتدا نمی‌تواند نرم‌افزار کامل را مشاهده کند، ممکن است تصور غلطی از نرم‌افزار نهایی پیدا کند، زیرا مشتری ظاهراً یک نسخه‌ی کاری از نرم‌افزار را می‌بیند. ولی نمی‌داند که این نمونه‌ی اولیه فقط یک «ماکت» است که با «موم» ‏سرهم‌بندی شده است.

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

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

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

مدل‌های تکاملی سنتی

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

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

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

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

توجه: در مدل‌های تکاملی در هر دور از تکرار نسخه‌ی کامل‌تری از نرم‌افزار تولید می‌شود.

مکانیزم نمونه‌سازی تکاملی

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

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

مدل افزایشی

‏مدل افزایشی (Incremental Model)، مراحل مدل آبشاری را با رویکرد تکرار و تکامل مکانیزم نمونه‌سازی تکاملی ترکیب نموده است. بنابراین مدل افزایشی مبتنی بر مدل آبشاری و مکانیزم نمونه‌سازی تکاملی است.

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

‏این مدل از یک سری فعالیت‌های چارچوبی تکراری تشکیل شده است که هر تکرار (افزایش) شبیه به مدل آبشاری است. با این تفاوت که روی قسمتی از نرم‌افزار انجام می‌شود. هر کدام از این قسمت‌ها یک «قطعه» قابل تحویل را ایجاد می‌کند. شکل زیر مدل افزایشی و مراحل هر افزایش را نشان می‌دهد:

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

‏مثال: نرم‌افزار واژه‌پرداز که با استفاده از مدل افزایشی توسعه یافته است، به صورت زیر تحویل داده  می‌شود:

افزایش اول: عملیاتی از قبیل مدیریت فایل، تولید و ویرایش مستندات ‏

افزایش دوم: قابلیت‌های پیچیده‌تر در ویرایش و تولید مستندات ‏

افزایش سوم: چک کردن املاء و دستور زبان ‏

افزایش چهارم: قابلیت‌های پیشرفته‌ی صفحه‌بندی ‏

مشاهده می‌شود که محصول هر افزایش در مثال فوق، قطعه‌ای قابل تحویل است.

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

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

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

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

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

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

‏به علاوه، افزایش‌ها می‌توانند به گونه‌ای برنامه‌ریزی شوند که ریسک‌های تکنیکی را مدیریت کنند. برای مثال، یک سیستم جامع و کلی ممکن است نیاز به سخت‌افزار جدیدی داشته باشد که فعلاً در حال تولید است و تاریخ تحویل آن قطعی نیست. در نتیجه ‏می‌توان افزایش‌های اولیه را به نحوی برنامه‌ریزی کرد که به این سخت‌افزار نیازی نداشته باشد. بدین ترتیب این امکان به وجود می‌آید که بخشی از عملکردها بدون تأخیر غیر عادی به کاربر نهایی تحویل داده شود.

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

‏توجه: مدل افزایشی علاوه بر مدیریت ریسک‌های تکنیکی، از مکانیزم نمونه‌سازی دورانداختنی به عنوان راهکاری برای کاهش ریسک مربوط به شناسایی نیازمندی‌ها در هر افزایش استفاده می‌کند و به ریسک‌های دیگر پروژه مانند از دست دادن مدیران و اطلاعات به دلیل عدم مدیریت ریسک (تحلیل ریسک) توجه ندارد.

مدل پیچشی 

رویکرد مدل پیچشی (Spiral Model) را همانند مدل افزایشی در نظر بگیرید با این تفاوت اساسی که در مدل پیچشی مدیریت ریسک (تحلیل ریسک) در فعالیت برنامه‌ریزی به طور جدی و در تمام جوانب پروژه انجام می‌گیرد. اما در مدل افزایشی فقط ریسک مربوط به شناسایی درست نیازمندی‌ها در هر تکرار توسط مکانیزم نمونه‌سازی دورانداختنی و ریسک تکنیکی مدیریت می‌گردد.

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

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

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

‏این مدل از یک سری فعالیت‌های چارچوبی تکراری تشکیل شده است که هر تکرار (پیچش) شبیه به مدل آبشاری است. با این تفاوت که روی قسمتی از نرم‌افزار انجام می‌شود. هر کدام از این قسمت‌ها یک «قطعه» ‏قابل تحویل را ایجاد می‌کند. شکل زیر مدل پیچشی و مراحل هر پیچش را نشان می‌دهد:

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

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

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

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

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

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

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

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

در نتیجه کیفیت نرم‌افزار تولیدی بالا خواهد رفت. همچنین مدیر پروژه بر امور جاری کنترل دقیق دارد و همه‌ی مسایل و هزینه‌ها با توافق طرفین (مشتری و سازنده) صورت می‌گیرد. به این کنترل دقیق بر امور جاری پروژه در هر تکرار اصطلاحاً «نقاط عطف لنگرگاهی» (Anchor Point Milestones) نیز گفته می‌شود.

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

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

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

‏معایب مدل پیچشی

1- قانع کردن مشتری به ویژه در این مورد که تکامل پروژه قابل کنترل می‌باشد، کار دشواری است. در واقع ما برای انجام مراحل مختلف پروژه نیازمند تأمین بودجه از سوی مشتری هستیم و ممکن است خروجی‌های بخش‌های مختلف تکامل پروژه از نظر مشتری چندان مطلوب نباشد و در تأمین بودجه‌ی مورد نیاز کوتاهی کند.

2- این مدل براساس ارزیابی، در نظر گرفتن و تعیین کردن ریسک در هر چرخش بنا شده است که خود این ارزیابی و مدیریت ریسک نیازمند تخصص مورد نیاز خودش می‌باشد، بنابراین موفقیت این مدل فرآیند، کاملاً وابسته به تصمیمات و سیاست‌هایی است که فرد و یا گروه مدیریت ریسک اتخاذ می‌کنند.

3- ‏اگر یک ریسک بزرگ شناسایی و مدیریت نشود، ممکن است مشکلات غیرقابل پیش بینی را در نرم‌افزار به وجود آورد.

معایب مدل‌های تکاملی سنتی

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

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

‏به رغم مزایای غیرقابل تردید مدل‌های تکاملی سنتی، دغدغه‌های نیز وجود دارد:

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

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

2- ‏مدل‌های تکاملی سنتی چندان سریع نیستند. زیرا اگر تکامل آنها به سرعت انجام شود، فرآیند دچار بی‌نظمی می‌شود (مثلاً نیازمندی‌ها به خوبی شناسایی نمی‌شوند) و اگر خیلی کند باشد، ممکن است روی بهره‌وری تأثیر منفی بگذارد (مثلاً پروژه در زمان مورد انتظار نرسد).

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

‏توجه: امروزه، چالش پیش روی مهندسان نرم‌افزار، استفاده از مدل فرآیندی است که بتواند بین دو فاکتور مهم سرعت (تولید به موقع) و کیفیت (رضایت مشتری) موازنه برقرار کند.

مدل توسعه‌ی هم‌روند

اغلب سازمان‌های نرم‌افزاری، در یک بازه‌ی زمانی، احتمالاً چندین پروژه را در دست تولید دارند. بسیاری از مهندسان نرم‌افزار معتقدند مدل‌های قبلی نمی‌توانند تصویر دقیقی از وضعیت یک پروژه در اختیار مدیران قرار دهند.

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

‏وضعیت‌های مختلف فعالیت‌های چارچوبی

1- انجام نشده: مانند زمانی که فعالیت ارتباط با مشتری آغاز شده است، اما فعالیت طراحی هنوز شروع نشده است.

2- ‏در حال توسعه: فعالیت چارچوبی که در حال انجام است، در این وضعیت قرار دارد.

3- ‏در حال مرور و معیارها: کارهای انجام شده براساس لیست نیازمندی‌ها و استانداردها، شاخص‌ها و معیارهای مشتری مرور و اعتبارسنجی می‌شوند.

4- ‏منتظر تغییرات: اگر فعالیتی در وضیعت در حال توسعه یا انجام شده باشد و تغییراتی در روند انجام پروژه ایجاد گردد، فعالیت موجود به وضعیت منتظر تغییرات جهت انجام تغییرات می‌رود.

5- ‏در حال بازبینی: اگر فعالیتی در وضعیت منتظر تغییرات قرار گرفت، پس از اعمال تغییرات، تغییرات انجام شده در وضعیت بازبینی باید مورد اعتبار سنجی قرار گیرد و در ادامه براساس معیارها مرور گردد.

6- انجام شده: هر مرحله از کار بعد از اینکه با توجه به معیارها و شاخص‌ها بازبینی شد و مورد تأیید قرار گرفت، به این مرحله وارد می‌شود و تا بروز تغییرات جدید در این مرحله می‌ماند.

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

هر کدام از این فعالیت‌ها در هر لحظه می‌تواند در یکی از وضعیت‌های نشان داده شده در شکل زیر قرار گیرد:

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

نتیجه اینکه در هر پروژه چندین فعالیت چارچوبی انجام می‌شود که هر کدام در وضعیت‌های متفاوتی قرار دارند. در این مدل، یکسری رویداد تعریف می‌شود که وقوع آنها باعث انتقال از وضعیتی به وضعیت دیگر برای هر یک از فعالیت‌های چارچوبی می‌گردد. برای مثال، وقوع یک ناسازگاری در فعالیت طراحی در طول مراحل اولیه آن که ناشی از وجود اشکال در فعالیت تحلیل بوده است، باعث انتقال فعالیت تحلیل از وضعیت «انجام شده» ‏به حالت «منتظر تغییرات» ‏و سپس در «‏حال بازبینی» می‌شود.

‏خصوصیات مدل توسعه‌ی هم‌روند

1- در دنیای واقعی، مدل توسعه‌ی هم‌روند را در تولید تمامی انواع نرم‌افزارها می‌توان به کار برد و این مدل، تصویری درست از وضعیت جاری یک پروژه را نمایش می‌دهد.

2- در مدل توسعه‌ی هم‌روند، به جای تعریف ترتیبی برای فعالیت‌های چارچوبی، شبکه‌ای از فعالیت‌های چارچوبی برای هر پروژه خواهیم داشت. به نحوی که رخدادهای یک فعالیت روی وضعیت آن فعالیت و سایر فعالیت‌های دیگر تأثیر می‌گذارد.

مدل توسعه‌ی مبتنی بر مؤلفه ساخت‌یافته

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

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

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

2) تابع سیستمی: مانند تابع سینوس که کامپایلر تعاریف آن را فراهم می‌کند و می‌تواند به عنوان یک قطعه‌ی آماده و قابل استفاده‌ی مجدد، در پروژه‌ها مورد استفاده مجدد قرار گیرد.

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

‏روال استقرار تابع در معماری نرم‌افزار (ساختار برنامه یا اسکلت برنامه) براساس مدل توسعه‌ی مبتنی بر مؤلفه‌ی ساخت‌یافته به صورت زیر است:

1- شناسایی توابع مورد نیاز برنامه

2- ‏جستجوی توابع در کتابخانه‌ی توابع سیستمی یا کاتالوگ توابع کاربردی

توجه: توابع کاربردی ایجاد شده در پروژه‌های قبلی در کاتالوگ توابع کاربردی، نگهداری می‌شوند.

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

4- ‏تابع در معماری نرم‌افزار (اسکلت برنامه) استقرار می‌یابد.

5- انجام تست برای اطمینان از صحت کار انجام می‌شود.

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

توجه: زمان و هزینه‌ی فرآیند تولید نرم‌افزار براساس مدل توسعه‌ی مبتنی بر مؤلفه ساخت‌یافته به دلیل استفاده از قطعات آماده (قابلیت استفاده مجدد) کاهش چشمگیری دارد. در واقع یک قطعه با قابلیت استفاده‌ی مجدد یک بار ساخته می‌شود و بارها و بارها استفاده می‌شود و این یعنی سودآوری!

مدل روش‌های رسمی

‏مدل روش‌های رسمی (فرمال، قراردادی و صوری) یا Formal Method شامل مجموعه‌ای از فعالیت‌ها است که سعی دارد پروژه‌ی نرم‌افزاری را در قالب روابطی رسمی و ریاضی، سیستم‌های کامپیوتری را تعریف، توسعه، پیاده‌سازی و ارزیابی نماید. در این مدل، با استفاده از تحلیل‌های ریاضی، بسیاری از ابهامات، نواقص و عدم سازگاری نرم‌افزار را تا حد زیادی می‌توان به سادگی کشف و تصحیح نمود. گونه‌ای از روش‌های رسمی وجود دارد که به مهندسی نرم‌افزار اتاق تمیز یا Clean Room معروف است.

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

توجه: یکی از مهمترین کاربردهای مدل روش‌های رسمی، ساخت سیستم‌های حساس و امن مانند ساخت نرم‌افزارهای کنترل هواپیما و موشک است. ‏

معایب مدل‌های روش‌های رسمی

1- استفاده از مدل روش‌های رسمی بسیار وقتگیر و گران است.

2- ‏آموزش گسترده‌ی سازندگان نرم‌افزار به علت اینکه تعداد اندکی از تولیدکنندکان نرم‌افزار پیش‌زمینه‌ی لازم برای به کار بردن روش‌های فرمال (رسمی) را دارند.

3- ‏از این مدل نمی‌توان برای برقراری ارتباط با مشتریان معمولی که دید فنی ندارند، استفاده نمود.

مدل توسعه‌ی مبتنی بر مؤلفه شیء­گرا

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

‏در دیدگاه شیءگرا، به مؤلفه پیمانه نیز گفته می‌شود. در حیطه مهندسی نرم‌افزار شیءگرا، واحد مؤلفه، یک قطعه‌ی عملیاتی مبتنی بر کلاس است که بر دو نوع می‌باشد:

1) کلاس کاربردی: مانند کلاس دانشجو که برنامه‌نویس آن را می‌نویسد و به دلیل داشتن شرایط قابل حمل به شکل ذاتی، می‌تواند به عنوان یک قطعه‌ی آماده و قابل استفاده‌ی مجدد در پروژه‌های بعدی مورد استفاده مجدد قرار گیرد.

2) کلاس سیستمی: مانند کلاس جعبه‌ی متن که کامپایلر تعاریف آن را فراهم می‌کند و می‌تواند به عنوان یک قطعه‌ی آماده و قابل استفاده‌ی مجدد، در پروژه‌ها مورد استفاده مجدد قرار گیرد.

‏این مدل از نظر ماهیت، مدلی تکاملی است و ساختاری تکرار‌شونده را برای توسعه‌ی نرم‌افزار در پیش می‌گیرد. اما در تولید برنامه‌های کاربردی از مؤلفه‌های آماده استفاده می‌کند، در واقع این مدل، برنامه را با استفاده از ترکیب و سرهم­کردن قطعات نرم‌افزاری از پیش ساخته شده می‌سازد.

‏روال استقرار کلاس در معماری نرم‌افزار (ساختار برنامه یا اسکلت برنامه) براساس مدل توسعه‌ی مبتنی بر مؤلفه شیءگرا به صورت زیر است:

1- شناسایی کلاس مورد نیاز برنامه

2- ‏جستجوی کلاس در کتابخانه‌ی کلاس‌های سیستمی یا کاتالوگ کلاس‌های کاربردی

توجه: کلاس‌های کاربردی ایجاد شده در پروژه‌های قبلی در کاتالوگ کلاس‌های کاربردی، نگهداری می‌شوند.

3- ‏در صورت وجود کلاس‌های مورد نیاز در کتابخانه‌ی کلاس‌های سیستمی یا کاتالوگ کلاس‌های کاربردی، کلاس استخراج و دوباره استفاده می‌شود. در غیراینصورت کلاس مورد نیاز ایجاد می‌گردد.

4- کلاس در معماری نرم‌افزار (اسکلت برنامه) استقرار می‌یابد.

5- انجام تست برای اطمینان از صحت کار انجام می‌شود.

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

توجه: زمان و هزینه‌ی فرآیند تولید نرم‌افزار براساس مدل توسعه‌ی مبتنی بر مؤلفه شیءگرا به دلیل استفاده از قطعات آماده (قابلیت استفاده مجدد) کاهش چشمگیری دارد. در واقع یک قطعه با قابلیت استفاده‌ی مجدد یک بار ساخته می‌شود و بارها و بارها استفاده می‌شود و این یعنی سودآوری!