مهندسی خواسته ها

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

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

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

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

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

پ.ن : یکی از دوستان باگ کوچکی در برنامه Darkpad پیدا کرده بود که خوشبختانه رفع شد. (با تشکر از امیرحسین عزیز) بنده به اشتباه کتابخانه Qt را در برنامه include کرده بودم که Darkpad هیچ نیازی به آن نداشت. به همین خاطر در هنگام اجرا با خطایی مبنی بر یافت نشدن فایل qtintf70.dll دریافت می کردید. نسخه جدید (0.5 آزمایشی) چنین مشکلی ندارد و در همه سیستم عامل های ویندوز بدون نیاز به نصب اجرا خواهد شد. Darkpad 0.5 را از اینجا دریافت کنید.

farasun.wordpress.com

Subcribe to Farasun feedمشترک فراسان شويد

farasun.wordpress.com

مطالب مرتبط :

نوشته های دیگر من درباره مهندسی نرم افزار

زمان بندی پروژه های نرم افزاری

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

farasun.wordpress.com

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

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

فرآیند زمان بندی پروژه های نرم افزاری

فرآیند زمان بندی پروژه های نرم افزاری

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

farasun.wordpress.com

Subcribe to Farasun feedمشترک فراسان شويد

farasun.wordpress.com

مطالب مرتبط :

مسئولیت های تخصصی و اخلاقی یک مهندس نرم افزار

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

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

بدین ترتیب، موسسات و سازمان های تخصصی نقش مهمی دارند. سازمان هایی مثل ACM ، IEEE و BCS دستورالعمل های اخلاقی و رفتاری را منتشر کرده اند و اعضای این سازمان ها هنگام عضویت، تعهد می دهند که این اصول را رعایت کنند. ACM و IEEE سعی کردند دستورالعمل های اخلاقی و تخصصی را بوجود آورند. هدف این دستورالعمل را در زیر شرح می دهیم.

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

اصول اخلاقی مهندسی نرم افزار (ACM/IEEE-1999) مشاهده نسخه اصلی

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

  1. Public : مهندسین نرم افزار به نفع عموم کار می کنند.
  2. Client and Employer : مهندسین نرم افزار طوری عمل می کنند که به نفع کارکنان و مشتریان باشد و با نفع عمومی سازگاری داشته باشد.
  3. Product : مهندسین نرم افزار تضمین می کنند که محصولات و اصلاحات آن ها از بالاترین استاندارد تخصصی پیروی می کنند.
  4. Judgement : مهندسین نرم افزار جامعیت و استقلال را در قضاوت تخصصی خود حفظ می کنند.
  5. Management : مدیران و رهبران مهندسین نرم افزار، توسعه و نگهداری نرم افزار را بر اساس اصول اخلاقی انجام می دهند.
  6. Profession : مهندسین نرم افزار جامعیت و شهرت را مطابق با منافع عموم گسترش می دهند.
  7. Colleagues : مهندسین نرم افزار حامی همکاران خود هستند و با آن ها با عدالت برخورد می کنند.
  8. Self : مهندسین نرم افزار سعی در آموزش بیشتر در حرفه خود دارند و اخلاقیات را نیز رعایت می کنند.

حالا به من بگید چند تا مهندس نرم افزار با مشخصات بالا سراغ دارید؟

توسعه تکاملی

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

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

دو نوع توسعه تکاملی وجود دارد :

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

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

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

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

مطالب مرتبط : مدل های فرآند نرم افزار | مهندسی نرم افزار | رهیافت آبشاری

رهیافت آبشاری

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

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

2- طراحی سیستم و نرم افزار : فرآیند طراحی سیستم ها، خواسته ها را به سیستم های نرم افزاری و سcrystal_clear_app_3d.pngخت افزاری تقسیم می می کند. بدین ترتیب، یک معماری کلی بوجود می آید. طراحی نرم افزار شامل شناسایی و توصیف انتزاع های سیستم نرم افزار و روابط آن هاست.

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

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

5- به کارگیری و نگهداری : این مرحله، معمولاً طولانی ترین مرحله چرخه حیات نرم افزار است. سیستم نرم افزاری نصبabshari.jpg و به کار گرفته می شود. نگهداری شامل تصحیح خطاهایی است که در مراحل اولیه چرخه حیات برطرف نشدند، شامل بهبود پیاده سازی های واحدهای سیستم و اصلاح خدمات سیستم جهت پاسخگویی به نیازهای جدید نیز است.

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

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

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

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

پ.ن : این مدل، قدیمی ترین مدل توسعه ی نرم افزار است که هنوز هم توسط شرکت ها و گروه های نرم افزاری سراسر دنیا مورد استفاده قرار می گیرد.

دریافت این نوشته در قالب PDF

مدل های فرآیند نرم افزار

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

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

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

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

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

4- توسعه مبتنی بر استفاده مجدد : در این رهیافت فرض می شود که تعدادی از مولفه های سیستم وجود دارند که دوباره قابل استفاده اند. فرآیند توسعه سیستم این مولفه ها را جامعیت می بخشد. در این رهیافت حداکثر بهره را از امکانات و مولفه های آماده و قابل استفاده می بریم. بسیاری از نرم افزارها که بر پایه یک نرم افزار دیگر توسعه می یابند از همین روش استفاده می کنند و برای رسیدن به اهداف تعیین شده ی خود از مولفه های آماده استفاده می کنند. مولفه های نرم افزاری آماده رهیافت توسعه ی یک نرم افزار را سرعت بخشیده و باعث کاهش خطا و باگ در آن می شود.

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

دریافت این نوشته در قالب PDF

پ.ن 1 : هر یک از فرآیندهای بالا در پست های جداگانه مورد بررسی قرار خواهند گرفت.

پ.ن 2 : به خاطر غیبت طولانیم از تمامی دوستان و خوانندگان ثابت و غیر ثابت وبلاگ به صورت رسمی معذرت خواهی می کنم.

مهندسی سیستم

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

سيستم را به روش هاي گوناگوني تعريف نموده اند ولي يکي از تعاريف ساده و کامل آن به اين صورت است : «سيستم مجموعه اي هدف مند از مولفه هاي مرتبط به هم است که با هم کار مي کنند تا هدفي را برآورده نمايند.»

دانلود مقاله در قالب PDF | بخش مقالات وبلاگ

ادامه‌ی خواندن