https://virgool.io/feed/@m_301666 fa 2026-06-21 11:54:39 https://files.virgool.io/upload/users/265792/avatar/ARyURP.jpeg?height=120&width=120 https://virgool.io/@m_301666 https://virgool.io/@m_301666/software-processing-pgcbfng9lu1z در مقاله قبل به تعریف نرم افزار و مهندسی نرم افزار پرداختیم و اجمالا فرایند مهندسی نرم افزار و فعالیت های چارچوبی آن را بررسی کردیم. در ادامه مقاله قبل، در اینجا به طور مبسوط به بررسی انواع مدل های فرایند نرم افزار می پردازیم. امید است که این مقاله برای خوانندگان مثمر ثمر واقع شود.یک مدل فرایند کلیفرایند به عنوان مجموعه ای از فعالیت های کاری، کنش ها و وظایف تعریف می شود، که هنگام ایجاد یک محصول باید اجرا شوند. هر کدام از این فعالیت ها، کنش ها و وظایف در یک چارچوب یا مدل قرار دارند که رابطه آنها را با فرایند و با یکدیگر تعریف می کند. شکل زیر طرحی از فرایند نرم افزار را نشان می دهد.شکل 1با توجه به شکل 1 فرایند نرم افزار شامل یک چارچوب فرایند کلی است که شامل پنج فعالیت چارچوبیِ ارتباطات، برنامه ریزی، مدل سازی، ساخت و استقرار می شود. به علاوه فرایندهای نرم افزاری شامل مجموعه ای از فعالیت های چتری می شوند که عبارتند از: کنترل و پیگیری پروژه، مدیریت ریسک، تضمین کیفیت، مدیریت پیکربندی و بازبینی های فنی، که در سرتاسر پروژه به کار گرفته می شوند.یک جنبه مهم از فرایند نرم افزار جریان فرایند است که شرح می دهد که فعالیت های چتری و کنش ها و وظایفی که در داخل هر فعالیت چارچوبی رخ می دهند از نظر ترتیب زمانی چگونه سازماندهی می شوند.در یک جریان فرایند خطی، هر کدام از فعالیت های چارچوبی به ترتیب اجرا می شود، به طوری که با ارتباطات آغاز و به استقرار ختم می شود(شکل 2). در یک جریان فرایند مبتنی بر تکرار، پیش از رفتن به دور تکرار بعدی، یک یا چند فعالیت تکرار می شوند(شکل 3). در جریان فعالیت تکاملی، فعالیت ها به شیوه ای حلقوی اجرا می شوند. هر مدار از پنج فعالیت عبور می کند که به نسخه کامل تری از نرم افزار می انجامد(شکل 4). در جریان فرایند موازی(شکل 5) یک یا چند فعالیت به موازات سایر فعالیت ها انجام می شوند.شکل 2شکل3شکل 4شکل 5تعریف یک فعالیت چارچوبییک پرسش کلیدی در اینجا مطرح است که: اگر ماهیت مساله، خصوصیات افرادی که کار را انجام می دهند و طرف های ذی نفعی که پروژه را پشتیبانی می کنند، معلوم باشد، کدام کنش ها برای یک فعالیت چارچوبی مناسب خواهد بود؟برای یک پروژه نرم افزاری کوچک که یک نفر با خواسته های صریح و ساده درخواست می کند، فعالیت برقراری ارتباط ممکن است شامل چیزی در حد یک تماس تلفنی با ذی نفع مورد نظر باشد. بنابراین تنها کنش لازم، مکالمه تلفنی است و وظایف کاری (مجموعه وظایف) که این کنش شامل آنها می شود، عبارتند از:بحث درباره خواسته ها و یادداشت برداشتن سازماندهی یادداشت ها در یک بیان مختصر از خواسته ها ارسال ایمیل برای بازبینی و تصویباگر پروژه به واسطه وجود تعداد زیادی از طرف های ذی نفع پیچیدگی بیشتری می یافت، که هر کدام مجموعه ای متفاوت از خواسته ها را دارند، فعالیت ارتباطات ممکن است شش کنش متمایز داشته باشند: شروع (inception)، استخراج (elicitation)، شناخت (elaboration)، مذاکره (negotiation)، تعیین مشخصات (specification) و اعتبارسنجی (validation). هر کدام از این کنش های مهندسی نرم افزار دارای چندین وظیفه کاری و تعدادی محصولات کاری متمایزند.تعیین مجموعه وظایفبا رجوع به شکل یک، هر کنش مهندسی نرم افزار (مثلا استخراج که کنشی مرتبط با فعالیت ارتباطات است) را می توان با تعدادی از مجموعه وظایف متفاوت نشان داد که هر کدام مجموعه ای از وظایف کاری در مهندسی نرم افزار مرتبط با محصولات کاری، نقاط تضمین کیفیت و نقاط عطف پروژه اند. باید مجموعه وظایفی را برگزینید که نیازهای پروژه را به بهترین نحو برآورده سازد و خصوصیات تیم شما را دربرگیرد.انواع مدل های فرایند نرم افزارانواع مدل های فرایند نرم افزار شامل موارد زیر می شود:مدل های فرایند تجویزی(سنتی)مدل های فرایند تخصیص یافتهفرایند یکپارچهمدل های فرایند تیمی و شخصیانواع مدل های فرایند نرم افزارمدل های فرایند تجویزی(سنتی)در این بخش به بررسی روش های فرایند تجویزی خواهیم پرداخت، که در آن نظم و سازگاری پروژه، مسائل عمده به شمار می رود. ما آنها را تجویزی می نامیم زیرا مجموعه ای از عناصر فرایند- فعالیت های چارچوبی، عملیات مهندسی نرم افزار، وظایف، محصولات کاری، تضمین کیفیت و سازوکارهای کنترل تغییرات را برای هر پروژه تضمین می کنند. هر مدل فرایند همچنین یک جریان فرایند(یا جریان کاری) را تعریف می کند. که شیوه ارتباط میان عناصر فرایند را تعریف می کند. این مدل ها شامل موارد زیر هستند:مدل آبشاریمدل های فرایند افزایشیمدل های فرایند تکاملیمدل توسعه همروندمدل آبشاریگاه پیش می آیدکه خواسته های مربوط به یک مسئله به خوبی شناخته شده اند- هنگامی که کار به طریق خطی، از برقراری ارتباط تا استقرار جریان پیدا می کند(شکل 6). این وضعیت هنگامی مشاهده می شود که تطبیق خوش تعریف یا بهسازی یک سیستم موجود ضرورت پیدا می کند.شکل 6در مدل آبشاری که گاه از آن به عنوان چرخه حیات کلاسیک یاد می شود، روشی سیستماتیک و ترتیبی برای توسعه نرم افزار پیشنهاد می شود که با مشخص کردن خواسته ها توسط مشتری آغاز می شود و از طریق برنامه ریزی، مدل سازی، ساخت و استقرار پیش می رود و در پشتیبانی مستمر نرم افزار کامل شده به اوج می رسد.از جمله مشکلاتی که به هنگام اجرای مدل ترتیبی خطی پیش می آید، می توان به موارد زیر اشاره کرد:پروژه های واقعی به ندرت جریان ترتیبیِ پیشنهاد شده توسط این مدل را دنبال می کنند. گر چه مدل خطی می تواند پذیرای تکرار باشد، این عمل را به طور غیرمستقیم انجام می دهد. در نتیجه، با پیش رفتن پروژه، ممکن است تغییرات باعث سردرگمی شوند.غالبا برای مشتری دشوار است که همه نیازهای خود را به وضوح بیان کند. مدل ترتیبی خطی، به بیان واضح نیاز دارد و به خوبی از پس موارد غیر قطعی که در آغاز اکثر پروژه ها وجود دارند بر نمی آید.مشتری باید حوصله داشته باشد. یک نسخه کاری از برنامه ها تا آخرین روزهای پروژه در دسترس او قرار نخواهد گرفت. یک اشتباه عمده که تا زمان بازبینی برنامه کاری از دید پنهان بماند، می تواند بسیار دردسر آفرین باشد.مدل های فرایند افزایشیبا رجوع به شکل 7، مشاهده می شود که مدل افزایشی، مراحل ترتیبی خطی را به شیوه ای باورنکردنی با پیشرفت تقویم اجرا می کند، هر ترتیب خطی یک ((افزایش)) قابل تحویل از نرم افزار را ارائه می دهد.شکل 7در واقع در مدل فرایند افزایشی در هر گام یک نسخه از نرم افزار در اختیار مشتری قرار می گیرد که این نسخه نسبت به نسخه های قبلی خود کامل تر می باشد و خدمات بیشتری به مشتری ارائه می دهد. در تولید هر کدم از این نسخه ها از عناصر مدل ترتیبی خطی استفاده می شود.این مدل به تحویل قطعه ای در هر گام تاکید می ورزد، قطعات اولیه نسخه ((دست و پا شکسته ای)) از محصول نهایی هستند ولی قابلیت ارائه خدمات به کاربر را دارند.مدل های فرایند تکاملیمدل های فرایند تکاملی شامل موارد زیر هستند:ساخت نمونه اولیهمدل مارپیچی(حلزونی)مدل ساخت نمونه اولیهالگوی ساخت نمونه اولیه با جمع آوری خواسته ها آغاز می شود. مشتری اهداف کلی نرم افزار را مشخص می کند، سپس یک طراحی سریع صورت می پذیرد. این طراحی سریع منجر به ساخت نمونه اولیه می شود. نمونه اولیه مورد ارزیابی مشتری قرار می گیرد و از آن برای پالایش خواسته های نرم افزار مورد نظر استفاده می شود. در حالت ایده آل نمونه اولیه به عنوان راهکاری برای تشخیص خواسته های نرم افزار عمل می کند.شکل 8ساخت نمونه اولیه به دلایل زیر مشکل آفرین است:مشتری فکر می کند که با کمی تغییر در نمونه اولیه می توان از آن به عنوان محصول نهایی استفاده کرد، در حالی که او نمی داند این نمونه اولیه بدون در نظر گرفتن کیفیت کلی نرم افزار و قابلیت نگهداری دراز مدت و با شتاب طراحی و ساخته شده است.مهندس نرم افزار غالبا برای به کارگیری هر چه سریع تر نمونه اولیه، در پیاده سازی دقیق آن کوتاه می آید. ممکن است از الگوریتم ها و زبان های برنامه نویسی ناکارآمد استفاده کند. پس از مدتی ممکن است برنامه نویس با این انتخاب ها مانوس شود و کلا فراموش کند که چرا نامناسب بوده اند، انتخاب کمتر از ایده آل اکنون به بخشی از سیستم تبدیل شده است.ممکن است این مشکلات به وجود آید، ولی ساخت نمونه اولیه می تواند الگوی موثری برای مهندسی نرم افزار باشد. کلید کار، تعیین قواعد بازی در همان آغاز است. یعنی افراد ذی نفع و سازنده هر دو باید بپذیرند که نمونه اولیه بدین منظور ساخته می شود که به عنوان سازوکاری برای تعیین خواسته ها عمل کند. سپس دور انداخته می شود و نرم افزار واقعی با مد نظر قرار دادن کیفیت، مهندسی می شود.مدل مارپیچی(حلزونی)مدل مارپیچی یک مدل فرایند تکاملی است که ماهیت تکراری مدل ساخته نمونه اولیه را با جنبه های کنترلی و سیستماتیک مدل ترتیبی خطی (آبشاری) تلفیق می کند. با استفاده از این مدل، نرم افزار به صورت یک سری از نگارش های تکاملی توسعه می یابد. طی نخستین دورهای تکرار، نگارش تکاملی، ممکن است یک مدل کاغذی یا یک نمونه اولیه باشد. طی تکرارهای بعدی، هر بار نسخه کامل تری از سیستم، مهندسی شده و تولید می شود.شکل 9نخستین مدار مارپیچ ممکن است منجر به ایجاد مشخصه ای از محصول گردد، ولی عبورهای بعدی در اطراف مارپیچ برای ایجاد یک نمونه اولیه و سپس نسخه های پیچیده تری از نرم افزار به کار می رود. هر بار گذر از ناحیه برنامه ریزی، منجر به تنظیم دوباره طرح پروژه می شود.هزینه و زمانبندی بر اساس بازخورد حاصل از ارزیابی مشتری تنظیم می شود. به علاوه مدیر پروژه تعداد تکرارهای مورد نیاز برای کامل شدن نرم افزار را تنظیم می کند.مدل مارپیچی یک روش واقع گرا برای توسعه نرم افزارها و سیستم هایی در مقیاس انبوه است. از آنجا که نرم افزار به موازات پیشرفت فرایند، تکامل می یابد، سازنده و مشتری در هر سطح تکامل ریسک را بهتر درک کرده به آن واکنش نشان می دهند. مدل مارپیچی از ساخت نمونه اولیه به عنوان راهکاری برای کاهش ریسک استفاده می کند، ولی مهم تر آنکه سازنده را قادر می سازد تا روش ساخت نمونه اولیه را در هر مرحله از تکامل محصول به کار بندد.مدل های فرایند تخصیص یافتهاین مدل ها شامل موارد زیر می شود:توسعه مبتنی بر مولفه هامدل روش های رسمیتوسعه نرم افزار به روش جنبه گراتوسعه مبتنی بر مولفه ها (Component-Based Development)مولفه های نرم افزاری آماده(COTS)، توسط عده ای از فروشندگان این مولفه ها توسعه داده می شوند. عملکرد مورد نظر را با واسط های مناسب فراهم می آورند، به طوری که مولفه را می توان به خوبی در سیستم در حال ساخت الحاق کرد. توسعه مبتنی بر مولفه ها بسیاری از خصوصیات مدل مارپیچی را در بر می گیرد. ماهیتی تکاملی دارد و برای ایجاد نرم افزار به رویکردی تکراری نیاز دارد. به هر حال، در مدل توسعه مبتنی بر مولفه ها، برنامه های کاربردی از به هم پیوستن مولفه های نرم افزار آماده ساخته می شوند.مدل توسعه مبتنی بر مولفه ها شامل مراحل زیر می شود:1. محصولات مبتنی بر مولفه موجود، از نظر دامنه کاربرد مورد نظر بررسی و ارزیابی می شوند.2. مسائل مربوط به انسجام مولفه ها در نظر گرفته می شوند.3. برای چیدمان مولفه ها یک معماری نرم افزار طراحی می شود.4. مولفه ها در این معماری قرار داده می شوند.5. آزمونی جامع برای حصول اطمینان از عملکرد درست، به عمل می آید.مدل توسعه مبتنی بر مولفه ها، استفاده مجدد از نرم افزار را میسر می سازد. اگر استفاده مجدد از مولفه ها فرهنگ سازی شود، تیم مهندسی نرم افزار شما می تواند به کاهش زمان چرخه توسعه و نیز کاهش هزینه های پروژه دست پیدا کند.مدل روش های رسمی (Formal Methods Model)روش های رسمی، مهندس نرم افزار را قادر می سازند تا با اعمال یک نظم ریاضی شدید، سیستم کامپیوتری را مشخص کند، بسط دهد و وارسی نماید.با استفاده از این مدل، ابهام، ناقص بودن و ناسازگاری را می توان راحت تر کشف و تصحیح کرد، نه از طریق بازبینی خاص، بلکه از طریق به کارگیری تحلیل ریاضی. هنگامی که روش های رسمی در اثنای طراحی به کار برده می شوند، به عنوان مبنایی برای وارسی برنامه عمل کرده از این رو مهندس نرم افزار را قادر به کشف و تصحیح خطاهایی می سازند که ممکن بود در غیر این صورت مخفی بمانند.ملاحظات مربوط به قابلیت اجرای این مدل در محیط های تجاری شامل موارد زیر می شود:توسعه مدل های رسمی در حال حاضر بسیار وقت گیر و پرهزینه است.از آنجا که تعداد معدودی از نرم افزار سازان دارای زمینه لازم برای اجرای روش های رسمی هستند، آموزش گسترده ای مورد نیاز است.استفاده از مدل ها به عنوان راهکار ارتباطی با مشتریانی که دید فنی ندارند، دشوار است.نظر به این ملاحظات، روش های رسمی احتمالا در میان نرم افزار نویسانی هوادار پیدا می کند که باید نرم افزارهای ایمنی-حیاتی (safety-critical) (مثلا نرم افزارهای دستگاههای پزشکی و هوافضا) بسازند یا در میان آنهایی که در صورت بروز خطا در نرم افزار دستخوش زیان های اقتصادی کلان می شوند.توسعه نرم افزار به روش جنبه گرا (Aspect Oriented)هر فرایند نرم افزار که انتخاب شود، سازندگان نرم افزارهای پیچیده، مجموعه ای از ویژگی ها، عملکردها و محتویات اطلاعاتی متمرکز را پیاده سازی می کنند. این خصوصیات نرم افزاری متمرکز به صورت مولفه هایی (مثلا کلاس های شئ گرا) مدل سازی و سپس در حیطه ی یک معماری سیستم بنا می شوند. با پیچیده تر شدن سیستم های کامپیوتری مدرن، دغدغه های خاصی کل معماری را در بر می گیرد. برخی از این دغدغه ها خواص سطح بالای سیستم (نظیر امنیت و تحمل پذیری خطا) هستند. عده ای دیگر بر وظایف سیستم تاثیر می گذارند (مثل اعمال قواعد تجاری) در حالی که عده ای هم سیستماتیک هستند (مانند همزمان سازی وظایف یا مدیریت حافظه).هنگامی که این دغدغه ها در وظایف، ویژگی و اطلاعات سیستمی با یکدیگر تلاقی می کنند، غالبا از آنها به عنوان دغدغه های متلاقی (Crossing Concerns) یاد می شود. خواسته های جنبه گرا، آن دسته از دغدغه های متلاقی را تعریف می کنند که بر معماری نرم افزار تاثیر می گذارند. توسعه نرم افزار به روش جنبه گرا (AOSD)، که از آن غالبا به عنوان برنامه نویسی جنبه گرا نیز یاد می شود، یک الگوی مهندسی نسبتا جدید است که رویکردی فرایندی و روش شناختی برای تعریف، مشخص سازی، طراحی و ساخت جنبه ها ارائه می دهد.((سازوکارهایی به غیر از زیر روال ها و وراثت برای متمرکز ساختن بیان یک دغدغه ی متلاقی)).فرایند یکپارچه (Unified Process)اوایل دهه 1990، جیمز رومباف، گرادی بوچ و ایوار جیکابسون کار روی یک ((روش یکپارچه)) را آغاز کردند که بهترین ویژگی های هر کدام از روش های طراحی و تحلیل شئ گرا را تلفیق می کرد و ویژگی هایی از سایر کارشناسان در مدل سازی شئ گرا را بر آن منطبق می ساخت. نتیجه، زبان مدل سازی یکپارچه (uml) است که حاوی یک نمادگذاری قدرتمند برای مدل سازی و توسعه ی سیستم های شئ گرا است.زبان مدل سازی یکپارچه (uml) فن آوری لازم برای پشتیبانی از مهندسی نرم افزار شئ گرا را فراهم ساخت، ولی چارچوب فرایندی لازم را برای راهنمایی تیم های پروژه در به کارگیری این فن آوری ارائه نداد. طی چند سال بعد، جیکابسون، ریمباف و بوچ، فرایند یکپارچه را توسعه دادند که چارچوبی برای مهندسی نرم افزار شئ گرا با استفاده از uml است.پیش تر پنج فعالیت چارچوبی کلی را مورد بحث قرار دادیم و استدلال کردیم که از آنها می توان برای توصیف هر مدل فرایند نرم افزار استفاده کرد. فرایند یکپارچه نیز از این قاعده مستثنی نیست. در شکل 10، مراحل up و ارتباط آنها با فعالیت های چارچوبی کلی، تصویر شده است.شکل 10مرحله آغازین در up شامل هر دو فعالیت برقراری ارتباط با مشتری و برنامه ریزی می شود. از طریق همکاری با طرف های ذی نفع، خواسته های تجاری برای نرم افزار شناسایی می شود، یک معماری تقریبی برای سیستم پیشنهاد می شود و برنامه ریزی بنیادی برای ماهیت تکراری و افزایشی پروژه آتی توسعه داده می شود.مرحله شناخت شامل فعالیت های برقراری ارتباط و مدل سازی در مدل فرایند کلی می شود. در این مرحله، ((use case های)) مقدماتی که به عنوان بخشی از مرحله آغازین ایجاد شدند، پالایش یافته و بسط داده می شوند، به علاوه، در این مرحله نمایش معماری نیز بسط داده می شود تا پنج نمای متفاوت نرم افزار را در برگیرد- این پنج نما عبارتند از مدل use case، مدل خواسته ها، مدل طراحی، مدل پیاده سازی و مدل استقرار.مرحله ساخت در up، هم ارز فعالیت ساخت است که برای فرایند نرم افزار کلی تعریف شد. مرحله ساخت با استفاده از مدل معماری به عنوان ورودی، مولفه های نرم افزاری را که هر کدام از use caseها را عملیاتی می کنند، ایجاد می کند یا آنها را توسعه می دهد.مرحله گذار در up شامل آخرین مراحل در فعالیت ساخت در مدل کلی و اولین بخش از استقرار در مدل کلی می شود. نرم افزار برای آزمون بتا به کاربران نهایی داده می شود و بازخورد به دست آمده از کاربران هم نقایص و هم تغییرات لازم را گزارش می کند. در پایان مرحله گذار، هر ((افزایش)) نرم افزار به یک نسخه قابل استفاده تبدیل می شود.مرحله تولید در up منطبق بر فعالیت استقرار در فرایند کلی است. طی این مرحله، استفاده از نرم افزار، پایش می شود، محیط عملیاتی (زیرساخت) پشتیبانی می شود و گزارش نقایص و درخواست برای تغییرات، تسلیم و ارزیابی می شود.مدل های فرایند تیمی و شخصیاین مدل ها شامل موارد زیر هستند:فرایند نرم افزار شخصی (PSP)فرایند نرم افزار تیمی (TSP)فرایند نرم افزار شخصی (PSP)فرایند نرم افزار شخصی بر اندازه گیری شخصی محصول کاری تولید شده و کیفیت حاصل از محصول کاری تاکید دارد. به علاوه، در PSP مجری کار مسئول برنامه ریزی پروژه است و کنترل کیفیت همه محصولات کاری نرم افزاری ساخته شده بر عهده خود اوست. در مدل PSP پنج فعالیت چارچوبی تعریف می شود:برنامه ریزی: در این فعالیت، خواسته ها شناسایی می شود، و برآورد منابع و تعیین اندازه پروژه انجام می شود. به علاوه برآوردی از نقایص (تعداد نقایص پیش بینی شده برای کار) به عمل می آید. همه معیارها روی کاربرگ ها یا قالب ها ثبت می شوند. سرانجام، وظایف لازم برای توسعه نرم افزار تعیین و زمانبندی پروژه انجام می شود.طراحی سطح بالا: مشخصات خارجی برای هر کدام از مولفه هایی که قرار است تعیین شود و طراحی مولفه ها انجام می شود. نمونه های اولیه ساخته می شود، در حالی که هنوز عدم قطعیت هایی موجود است. همه مسائل و مشکلات، ثبت و پیگیری می شوند.مرور طراحی سطح بالا: روش های وارسی رسمی برای یافتن خطاهای طراحی، اعمال می شوند. معیارهای مربوط به وظایف مهم و نتایج کار، نگهداری می شود.توسعه: طراحی سطح بالا پالایش و بازبینی می شود. کدها تهیه، بازبینی، کامپایل و آزموده می شوند. معیارها برای کلیه وظایف مهم و نتایج کار، حفظ می شوند.پایان کار: با استفاده از معیارها و موازین جمع آوری شده (که مقادیر چشم گیری از داده ها را شامل می شود و باید مورد تحلیل آماری قرار گیرد)، اثربخشی فرایند تعیین می شود. موازین و معیارها باید راهنمایی برای اصلاح فرایند و بهبود بخشیدن به اثربخشی آن فراهم آورند.در PSP تاکید بر شناسایی زودهنگام خطاهاست و شناخت انواع خطاهایی که احتمال ارتکاب آنها وجود دارد نیز به همان اندازه اهمیت دارد. این هدف از طریق یک فعالیت ارزیابی طاقت فرسا قابل دستیابی است که باید روی کلیه محصولات کاریِ تولید شده اجرا شود.فرایند نرم افزار تیمی(TSP)هدف TSP تشکیل یک تیم پروژه ((خود هدایت گر)) است که سازماندهی برای تولید نرم افزارهای پر کیفیت را خود عهده دار می شود. فعالیت های زیر برای TSPتعریف می شود:تشکیل تیم های خود هدایت گری که کار خود را برنامه ریزی و پیگیری می کنند. اهداف را تعیین می کنند و خود به تعیین فرایندها و طرح ها اقدام می نمایند. این تیم ها می توانند تیم های نرم افزاری محض یا تیم های محصولات انسجام یافته (IPT) شامل سه تا حدود بیست مهندس باشند.نشان دادن شیوه راهبردی و ایجاد انگیزه در تیم ها به مدیران و چگونگی کمک به آنها در حفظ حداکثر کاراییشتاب بخشیدن به بهبود فرایند نرم افزار با نهادینه ساختن CMM سطح5. (مدل بلوغ شایستگی ها (CMM) که میزانی از اثر بخشی یک فرایند نرم افزار است).فراهم ساختن دستورالعمل بهسازی برای سازمان های بالغتسهیل آموزش دانشگاهی مهارت های تیمی در سطح صنعتییک تیم ((خود هدایت گر)) درک سازگاری از اهداف و مقاصد خود دارد. نقش ها و مسئولیت ها را برای هر عضو تیم تعریف می کند، داده های کمی پروژه (مربوط به بهره وری و کیفیت) را زیر نظر دارد، تیم پروژه ای را تعیین می کند که برای تیم مناسب باشد. و برای پیاده سازی فرایند، یک راهبرد تعیین می کند، استانداردهای محلی قابل استفاده را برای کار مهندسی نرم افزار تعریف می کند، خطرات را پیوسته ارزیابی می کند و به آن واکنش نشان می دهد، و سرانجام اینکه وضعیت پروژه را پیگیری، مدیریت و گزارش می کند.در TSP، فعالیت های چارچوبی زیر تعریف می شود: آغاز پروژه، طراحی سطح بالا، پیاده سازی، انسجام دهی و آزمون، و پایان کار. این فعالیت ها مانند همتاهای خود در PSP (توجه دارید که اصطلاحات قدری تفاوت دارند)، تیم را قادر به برنامه ریزی، طراحی و ساخت نرم افزار به شیوه ای منضبط می کند، در حالی که در عین حال، اندازه گیری کمی فرایند و محصول انجام می شود. مرحله پایان کار صحنه را برای بهسازی فرایند آماده می کند.نتیجه گیریاگر فرایند انتخابی ما برای یک پروژه ضعیف باشد، محصول نهایی بدون شک ضعیف خواهد بود. از این رو آگاهی و دانش در مورد انواع مدل های فرایند نرم افزاری امری لازم و ضروری می نماید، تا با انتخاب درست و بجای یک فرایند نرم افزاری بتوان نرم افزارهای قدرتمندی را توسعه داد. امید است که این مقاله بتواند به شما در توسعه پروژه های نرم افزاری یاری رساند. در مقاله بعد سعی می کنیم مطالب مرتبط با توسعه چابک را مطرح نموده و بیشتر با آن آشنا شویم.منبع: ویراست هفتم کتاب مهندسی نرم افزار نوشته راجر اس پرسمنمحمد باقر رفیعیان محمد باقر رفیعیان محمد باقر رفیعیان Sat, 07 Nov 2020 20:12:20 +0330 https://virgool.io/@m_301666/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%88-%D8%A7%D8%B5%D9%88%D9%84-%DA%A9%D9%84%DB%8C-%D8%A2%D9%86-fzbadvb4hk1g هدف ما از این مقاله و سلسله مقالات بعدی در رابطه با مهندسی نرم افزار که در آینده به آنها خواهیم پرداخت. بحث پیرامون ارائه یک چارچوبی است که سازندگان نرم افزارهای کامپیوتری بتوانند از آن برای تولید نرم افزارهای خود استفاده کنند. این چارچوب شامل یک فرایند، مجموعه ای از روش ها و آرایه ای از ابزارها می شود که آنها را مهندسی نرم افزار می نامند. منبع اصلی ما در این مقالات ویراست هفتم کتاب مهندسی نرم افزار تالیف راجر اس پرسمن (Rojer S .Pressman) می باشد.نرم افزاربحث را با تعریف نرم افزار و برشمردن خصوصیات آن آغاز می کنیم. پرسمن در کتاب خود نرم افزار را به گونه زیر تعریف می کند:نرم افزار عبارت است از: (۱) دستورالعمل هایی که هنگام اجرا، ویژگی، عملکرد و کارایی مطلوب را فراهم می سازند؛ (۲) ساختمان داده هایی که برنامه ها را قادر به پردازش مناسب داده ها کنند و (۳) اطلاعات توصیفی در هر دو قالب کپی سخت و مجازی که راه اندازی و استفاده از برنامه ها را شرح دهند.از آنجا که نرم افزار، یک عنصر منطقی است تا یک عنصر فیزیکی، دارای ویژگی هایی است که تفاوت زیادی با سخت افزار دارد:نرم افزار، مهندسی و بسط داده می شود و چیزی نیست که به معنای کلاسیک کلمه، ساخته شودنرم افزار فرسوده نمی شودشکل ۱-۱ نمودار آهنگ شکست را به صورت تابعی از زمان برای سخت افزار نشان می دهد. این رابطه که اغلب منحنی وانی نامیده می شود، نشان می دهد که سخت افزار در ابتدای عمر خود آهنگ شکست نسبتاً شدیدی دارد (این شکست را غالباً می توان به عیوب طراحی و تولید نسبت داد)، این عیوب تصحیح می شوند و آهنگ شکست برای یک دوره زمانی به مقداری ثابت نزول می کند. با گذشت زمان، سخت افزار شروع به فرسایش کرده و دوباره آهنگ شکست شدت می گیرد.رم افزار نسبت به ناملایمات محیطی که باعث فرسایش آن می شود، نفوذ پذیر نیست. بنابراین، در تئوری، منحنی شکست برای نرم افزار باید شکل منحنی ایده آل شکل ۲-۱ را به خود بگیرد. عیوب کشف نشده باعث آهنگ شکست شدید، در ابتدای عمر برنامه می شود، ولی این عیوب برطرف می شوند و منحنی به طوری که نشان داده شده است، هموار می شود. منحنی ایده آل نسبت به منحنی واقعی مدل های شکست نرم افزار بسیار ساده تر است. ولی معنای آن بسیار واضح است، نرم افزار هرگز دچار فرسایش نمی شود بلکه زوال می یابد.این تناقض ظاهری را می توان با در نظر گرفتن (منحنی واقعی) به بهترین وجه توضیح داد. نرم افزار در دوران حیات خود دستخوش تغییر می شود(نگهداری). با اعمال این تغییرات، احتمال دارد که برخی عیوب جدید وارد شوند و باعث خیز منحنی آهنگ شکست شوند. پیش از آنکه منحنی بتواند به آهنگ شکست منظم اولیه خود برسد، تغییر دیگری درخواست می شود که باعث خیز دوباره منحنی می شود. حداقل میزان شکست به آهستگی افزایش می یابد- نرم افزار در اثر تغییر فاسد می شود.گر چه صنعت در حال حرکت به سوی مونتاژ قطعات است، اکثر نرم افزارها همچنان به صورت سفارشی ساخته می شوند. در جهان سخت افزار، استفاده مجدد از قطعات، بخشی از فرایند مهندسی است. در مهندسی نرم افزار این امر به تازگی مورد توجه قرار گرفته است. در واقع یک مولفه نرم افزاری باید چنان طراحی و پیاده سازی شود که بتوان در برنامه های متفاوت از آن بهره برد.مهندسی نرم افزاربرای مهندسی نرم افزار تعارف متفاوتی ارائه شده است، IEEE مهندسی نرم افزار را اینگونه شرح می دهد: کاربرد یک روش سیستماتیک، علمی و کمیت پذیر در بسط، راه اندازی و نگهداری نرم افزار، یعنی استفاده از مهندسی نرم افزار.مهندسی نرم افزار یک فن آوری لایه ای است. با توجه به شکل ۳-۱، هر روش مهندسی (از جمله مهندسی نرم افزار) باید متکی به تعهد سازمانی به کیفیت باشد. در واقع سنگ بنای نگهدارنده مهندسی نرم افزار، توجه به کیفیت است.بنیاد مهندسی نرم افزار، لایه فرایند است. فرایند چارچوبی را تعریف می کند که باید برای تحویل موثر فناوری مهندسی نرم افزار وضع شود. فرایند نرم افزار، پایه ای برای کنترل مدیریتی پروژه های نرم افزاری تشکیل داده، بستری برای اعمال روش های فنی، تولید محصولات کاری (مدل ها، مستندات، داده ها، گزارشات، فرم ها و غیره)، تعیین مراحل، حصول اطمینان از کیفیت و مدیریت مناسب تغییرات ایجاد می کند.روش های مهندسی نرم افزار، شیوه های فنی برای ساخت نرم افزار را فراهم می آورند. این روش ها شامل آرایه وسیعی از وظایف از جمله: تحلیل خواسته ها، طراحی، ساخت برنامه ها، آزمایش و پشتیبانی می شود.ابزارهای مهندسی نرم افزار، متضمن پشتیبانی خودکار یا نیمه خودکار برای فرایند و روش هایی هستند. هنگامی که ابزارها گرد هم آیند به طوری که اطلاعات ایجاد شده توسط یک ابزار، توسط ابزارهای دیگر قابل استفاده باشند، سیستمی برای پشتیبانی نرم افزار شکل می گیرد که مهندسی نرم افزار به کمک کامپیوتر نام دارد.فرایند مهندسی نرم افزارچارچوب فرایند با تعیین تعداد کوچکی از فعالیت های چارچوبی که برای کلیه پروژه های نرم افزاری قابل استفاده باشند، صرف نظر از اندازه و پیچیدگی آنها، شالوده ای برای یک فرایند مهندسی نرم افزار کامل پی ریزی می کند. یک چارچوب فرایند کلی برای مهندسی نرم افزار شامل پنج فعالیت می شود.ارتباطات(Communication): پیش از اینکه هرگونه کار فنی آغاز شود، برقراری ارتباط و همکاری با مشتری بسیار مهم است. هدف، درک اهداف طرف های ذی نفع برای پروژه و جمع آوری خواسته هایی است که می توانند ویژگی ها و قابلیت های عملیاتی نرم افزار را تعیین کنند.برنامه ریزی(Planning): یک پروژه نرم افزاری، سفری پیچیده است و فعالیت برنامه ریزی، نقشه ای ایجاد می کند که به راهنمایی تیم در انجام این سفر کمک می کند. این نقشه با توصیف وظایف فنی که قرار است اجرا شوند، خطرات احتمالی، منابعی که مورد نیاز خواهند بود، محصولات کاری ای که باید تولید شوند و زمانبندی کاری، مهندسی نرم افزار را مشخص می کند.مدل سازی(modeling): یک معمار، هر روز با مدل ها کار می کند، اِتودی می زند تا تصویر بزرگ را درک کند، اینکه از نظر معماری چه ظاهری دارد، بخش های سازنده اش چگونه با هم جور در خواهند آمد، و بسیاری خصوصیات دیگر. مهندسی نرم افزار با ایجاد مدل هایی جهت درک بهتر خواسته ها و طراحی که به این خواسته ها برسد، همین کار را می کند.ساخت(Construction): این فعالیت، تولید کدها و آزمون لازم برای آشکار کردن خطاهای موجود در کدها را با هم تلفیق می کند.استقرار(Deployment): نرم افزار به مشتری تحویل داده می شود تا محصول تحویل داده شده را ارزیابی کرده و بر اساس این ارزیابی، بازخوردی ارائه دهد.برای بسیاری از پروژه های نرم افزاری، فعالیت های چارچوبی به موازات پیشرفت پروژه به صورت تکراری به کار برده می شوند. در هر دور از تکرار پروژه، یک نسخه از نرم افزار ایجاد می شود که زیر مجموعه ای از قابلیت های عملیاتی و ویژگی های نرم افزار کامل را در اختیار افراد ذی نفع قرار می دهد. با تولید هر نمو، نرم افزار کامل و کامل تر می شود.فعالیت های چارچوبی فرایند مهندسی نرم افزار توسط تعدادی از فعالیت های چتری تکمیل می شوند که عبارتند از: کنترل و پیگیری پروژه های نرم افزاری: به تیم نرم افزاری امکان می دهد تا پیشرفت را در مقایسه با نقشه پروژه بسنجد و هر گونه کنش لازم را برای حفظ زمان بندی به عمل آورد.مدیریت ریسک: خطراتی را ارزیابی می کند که ممکن است بر نتیجه پروژه یا کیفیت محصول تاثیر بگذارند.تضمین کیفیت نرم افزار: فعالیت های لازم برای حصول اطمینان از کیفیت نرم افزار را معین می کند.بازبینی فنی: محصولات کاری مهندسی نرم افزار را در تلاش برای آشکار کردن خطاها قبل از انتشار آنها در فعالیت بعدی و برطرف کردن آنها ارزیابی می کند.اندازه گیری: موازینی از فرایند، پروژه و محصول را تعریف می کند که نیازهای طرف های ذی نفع را برطرف می سازند.مدیریت پیکربندی نرم افزار: اثرات تغییرات را در سراسر فرایند نرم افزار مدیریت می کند.مدیریت قابلیت استفاده مجدد: ملاک های مربوط به استفاده مجدد (از جمله قطعات نرم افزاری) را تعریف می کند و سازوکارهایی برای دستیابی به قطعات قابل استفاده مجدد برقرار می سازد.تهیه و تولید محصول کاری: شامل فعالیت های لازم برای ایجاد محصولات کاری از قبیل مدل ها، مستندات، وقایع نگارها(کارنامه ها)، فرم ها و فهرست ها می شود.توجه به این نکته ضروری است که فرایند مهندسی نرم افزار یک دستورالعمل نهایی و غیر قابل تغییر نیست که تیم نرم افزاری باید با تعصب از آن پیروی کند بلکه باید سریع الانتقال و انطباق پذیر باشد(برای مساله، برای پروژه، برای تیم و برای فرهنگ سازمانی). بنابراین فرایندی که برای یک پروژه پذیرفته می شود، ممکن است با فرایند پذیرفته شده برای پروژه های دیگر تفاوتی چشمگیر داشته باشد. در مقالات بعدی مدل های مختلف فرایندها را شرح خواهیم داد.مهندسی نرم افزار در عملجورج پولیا در یک کتاب کلاسیک با عنوان (چگونگی حل مساله) که قبل از وجود کامپیوترهای مدرن نوشته شده است، جوهر حل مساله و در نتیجه (جوهر عمل) در مهندسی نرم افزار را چنین مطرح می کند:شناخت مساله (برقراری ارتباط و تحلیل)طرح ریزی برای یک حل (مدل سازی و طراحی نرم افزار)اجرای برنامه ریزی (ایجاد کد)بررسی نتیجه برای صحت (آزمایش و تضمیین کیفیت)اصول کلیدیوید هوکر هفت اصل را مطرح نموده است که توجه به آنها در مهندسی نرم افزار بسیار ضروری به نظر می رسد.اصل یکم) دلیل وجود سیستم: هر سیستم به یک وجود نیاز دارد: این که برای کاربرانش ارزش فراهم سازد. همه تصمیم گیری ها باید با مد نظر داشتن این نکته انجام شود.اصل دوم) ساده نگه داشتن: همه طراحی ها باید تا حد امکان ساده باشند. این باعث می شود که یک سیستم قابل فهم تر با قابلیت نگهداری بالاتر را داشته باشید.اصل سوم) حفظ چشم انداز: برای موفقیت یک پروژه نرم افزاری، چشم اندازی روشن، ضروری است و بدون آن پروژه تقریبا همواره به جایی می رسد که دو یا چند ایده بر آن حاکم خواهد شد. یک سیستم بدون یکپارچگی مفهومی، به مجموعه ی ناجوری از طراحی های ناسازگار تبدیل می شود که به یکدیگر وصله-پینه شده اند. مسامحه در مورد خصوص چشم انداز معماری یک سیستم نرم افزاری باعث تضعیف سیستمی با طراحی خوب و سرانجام از کار افتادن آن می شود.اصل چهارم) آنچه که شما تولید می کنید، دیگران مصرف می کنند: همواره تعیین مشخصات، طراحی و پیاده سازی را طوری انجام دهید که دیگران نیز قادر به درک کار شما باشند.اصل پنجم) آینده نگری: سیستمی با طول عمر بالا از ارزش بیشتری برخوردار است. سیستم ها باید آمادگی انطباق بر تغییرات را داشته باشند. سیستم هایی که این ویژگی ها را با موفقیت ارائه می دهند، از ابتدا با این ویژگی ها طراحی می شوند.اصل ششم) برنامه ریزی پیشاپیش برای استفاده مجدد: استفاده مجدد باعث صرفه جویی در زمان و کار می شود. استفاده مجدد از کد ها و طراحی ها به عنوان مزیت اصلی فن آوری های شیئ گرا مطرح شده است ولی این امکان در برنامه نویسی شیئ گرا نیازمند برنامه ریزی قبلی است.اصل هفتم) تفکر: این آخرین اصل احتمالاً بیش از بقیه مورد بی مهری قرار می گیرد. تعقل و تفکر کامل و روشن قبل از اقدام به عمل، همواره نتایج بهتری به بار می آورد. با تفکر روشن درباره سیستم، ارزش آن بالا می رود. به کارگیری شش اصل نخست نیاز به تفکر عمیق دارد و در این صورت، فایده بسیاری از آن عاید خواهد شد.محمد باقر رفیعیان محمد باقر رفیعیان محمد باقر رفیعیان Mon, 14 Sep 2020 23:52:46 +0430