ره آورد نور

کلید واژگان: تولید نرم افزار، تحلیل نرم افزار، توسعه نرم افزار.

روش های نرم افزاری

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

1. ترتیبی خطی یا آبشاری؛
2. پیش نمونه سازی؛
3. تکامل یافته؛
4. افزایشی؛
5. تولید سریع کاربردها؛
6. الگوی توسعه تجزیه تحلیل سیستم های ساخت یافته؛
7. حلزونی؛
8. مارپیچی برنده برنده؛
9. مونتاژ مؤلفه ها؛
10. توسعه هم روند؛
11. روش های رسمی ؛
12. فنون نسل چهارم؛
13. روش XP؛
14. روش CMM.

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

1. ترتیبی خطی یا آبشاری(2)

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

دیاگرام و مراحل کار، بسته به اجراء خطی یا آبشاری این الگو، به دو صورت ذیل ممکن می باشد:

روش ترتیبی خطی

روش ترتیبی آبشاری

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

- مهندسی اطلاعات یا سیستم(4):

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

مهندسی سیستم و تجزیه و تحلیل، شامل جمع آوری نیازها در سطح سیستم - به همراه تجزیه و تحلیل – و طراحی در سطح بالا می باشد. مهندسی اطلاعات، شامل جمع آوری نیازها در سطح تجارت راهبردی و محیط تجاری می باشد.

- تجزیه تحلیل نیازمندی های نرم افزار(5):

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

- طراحی(6):

طراحی نرم افزار، پروسه ای چند مرحله ای است که بر چهار ویژگی مجزای مسئله تأکید دارد:

• * ساختمان داده ها؛
• * معماری نرم افزار(7)؛
• * نمایش واسط ها؛
• * جزئیات رویه ای.

- تولید و توسعه کد(8):

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

- آزمایش(9):

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

- نگهداری(10):

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

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

1. پروژه های واقعی، به دلیل ماهیت متغیر و پویای بستر پروژه نرم افزاری، معمولاً جریان ترتیبی را که این روش پیشنهاد می نماید، دنبال نمی کنند.
2. برای مشتری مشکل است که به طور دقیق و یکجا تمام نیازهای خود را در ابتدای کار و آغاز پروژه بگوید.
3. طبق الگوی آبشاری، مشتری باید برای دیدن نتایج نهایی، تا انتهای کار صبر داشته باشد؛ زیرا نسخه ای از برنامه که کار می کند، اواخر پروژه در دسترس خواهد بود و اگر یک اشکال تا زمان تولید برنامه نهایی دیده نشود و یا نظر مشتری اعمال نگردد، می تواند مصیبت بار باشد.
4. ماهیت خطی این روش، باعث به وجود آمدن blocking states می شود که در این حالت، بعضی از اعضای تیم باید منتظر کامل شدن کار دیگران شوند. در واقع، زمان انتظار در این روش، بیشتر از زمان کار است. زمان انتظار، به خصوص در ابتدا و انتهای این روش، زیاد می شود.
5. در این روش، زمان بسیاری صرف کار می شود که خود باعث تغییر نیاز مشتری می شود.
6. در روش آبشاری یا خطی، برگشت به عقب و بازبینی و تصحیح عملکردها در مراحل مختلف، زمــان بر و هزینه بر است.

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

• - مستند مشخصات(11)؛
• - مستند طراحی(12)؛
• - مستند کدنویسی(13)؛
• - مستند کاربر(14)؛
• - مستند عملکرد برنامه(15)؛
• - نمونه های آزمایش(16).

2. پیش نمونه سازی(17)

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

روش پیش نمونه سازی

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

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

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

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

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

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

3. تکامل یافته(20)

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

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

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

4. افزایشی (21)

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

نمای کلی روش افزایشی

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

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

بنابراین، نسخه های قبلی دور ریخته نمی شوند. مراحل اوّلیه، نسخه های عریان محصول نهایی هستند؛ اما آنها قابلیت ارائه چارچوبی برای ارزیابی توسط کاربر را دارند. این روش، برای حالتی که پرسنل کافی برای اتمام پروژه در زمان تعیین شده کافی نباشد، مناسب است. مراحل اوّلیه می تواند با پرسنل کمتری صورت بگیرد. اگر هسته محصول به صورت کامل و خوب دریافت شده باشد، می توان پرسنل اضافه ای برای انجام مراحلِ بعدی به خدمت گرفت. علاوه بر این، مراحل این روش می تواند به صورتی طراحی شود که بتوان خطرهای فنی(23) را در نظر گرفت؛ به عنوان مثال، یک سیستم کلان ممکن است نیاز به سخت افزاری جدید داشته باشد که در حال ساخت است و زمان عرضه آن، مشخص نیست. بنابراین، باید بتوان مراحل اوّلیه را طوری طراحی کرد که از استفاده این سخت افزار، به دور باشند و در نتیجه، می توان بدون تأخیر نامنظم، خروجی با کارکرد جزئی برای ارائه به کاربر داشته باشیم. باید توجه داشت که در این روش، مجبور به انجام دوباره بعضی کارها هستیم که از نقاط ضعف آن به شمار می رود؛ ولی به هر حال، این روش برای بازار رقابتی گزینه مناسبی می باشد.

5. روش توسعه کاربردها(24)

یک روش پردازش ترتیبی خطی است که تأکید بر چرخه تولید کوتاه دارد. این روش، یک انطباق از روش ترتیبی خطی است که با شیوه مبتنی بر مؤلفه(25) ، به تولید سریع می رسد. اگر نیازمندی ها خوب شناخته شود و محدوده کار درست فرض شود، پروسه RAD ، تیم توسعه را به ساختن یک سیستم کامل با کارایی بالا و زمان بسیار کم تولید (معادل 60 ـ 90 روز کاری) قادر می سازد. در درجه اوّل، این شیوه در سیستم های اطلاعاتی استفاده می شود. از جمله محاسن کلیدی این الگو، تفکیک انواع فازها و رده های مدل سازی در گروه های مستقل است.

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

انواع طبقات مدل سازی و فازهای این روش در شکل ذیل آمده است:

روش توسعه سریع کاربردها

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

- مدل سازی تجاری(26):

در این الگو، فرآیند مدل سازی تجارت یا کسب وکار مورد نظر، با جواب دادن به سؤالات زیر، جریان داده ها در عملکرد تجاری خاصی را مدل سازی می کند:

• * چه اطلاعاتی فرآیندهای تجاری را راه اندازی می کند؟
• * چه اطلاعاتی تولید می شود؟
• * چه کسی این اطلاعات را تولید می کند؟
• * این اطلاعات کجا می روند و چه خروجی ایجاد می کنند؟
• * چه کسی این اطلاعات را پردازش می کند؟

- مدل سازی داده ای(27):

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

- مدل سازی فرآیند(28):

در این فاز، پردازش ها و روال های کاری برای اضافه کردن، تغییر، حذف و یا بازیابی اشیای داده، تحت کارکردهای خاصی تعریف می شوند.

- تولید برنامه کاربردی(29):

در این روش، تولید برنامه های کاربردی با استفاده از تکنیک های نسل چهارم(GT4) انجام می شود. به جای ساختن نرم افزار با استفاده از زبان های برنامه نویسی سنّتی، اگر ممکن باشد، RAD از اجزا و مؤلفه ها(30) و بخش های موجود استفاده می کند و یا اگر لازم باشد اجزای قابل استفاده مجدد تولید می کند. در تمام حالات، ابزار خودکار برای سرعت بخشیدن به تولید نرم افزار کاربردی استفاده می شود.

- دوره آزمون(31):

به دلیل اینکه روش توسعه سریع کاربردها بر اجزای قابل استفاده مجددِ تست شده تأکید دارد، بنابراین، زمان تست نرم افزارهای تولیدی در این روش کاهش می یابد. البته اجزای جدید نیاز به تست دارند و در نهایت، به تست جامع کل نرم افزار به صورت یکپارچه نیاز داریم.

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

بنابراین، می توان هر عمل اصلی را به یک تیم RAD سپرد و در نهایت، نتایج کار را به هم متصل و مجتمع سازی نمود.

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

• - برای پروژه های بزرگ، ولی قابل گسترش(32) ، این روش نیاز به منابع انسانی کافی دارد تا تیم های RAD را به تعداد ایجاد کند و نیز منابع انسانی باید دارای تعهد کاری باشند. این روش، تولیدکننده و مشتری را در یک چارچوب زمانی کوتاه، محدود می کند. اگر پروژه در این فاصله تمام نشود، پروژه RAD از بین می رود.
• - تمام انواع پروژه ها، برای RAD مناسب نیستند. اگر یک سیستم را نتوان به صورت مناسب به پیمانه هایی مستقل تقسیم کرد، ساختن اجزای ضروری برای RAD مشکل ساز خواهد بود.
• - اگر کارایی بالا مدنظر باشد و بخواهیم این کارایی را از طریق تنظیم واسطه های اجزای سیستم(33) به دست آوریم، روش به صورت مناسب کار نخواهد کرد.
• - RAD هنگامی که احتمال خطرات فنی بالا باشد، مناسب نیست. این امر زمانی اتفاق می افتد که یک برنامه به یک فناوری جدید وابستگی داشته باشد و یا یک نرم افزار جدید نیاز به درجه بالایی از کنش پذیری(34) برنامه های رایانه ای موجود داشته باشد. در چنین مواردی، به کارگیری الگوی مدل سازی باعث کاهش کنش پذیری متقابل بین اجزای نرم افزاری و ماژول ها و بسته نرم افزاری می گردد و تعاملات را دشوار می سازد. در این گونه موارد، غالباً به کارگیری روش ها شیئ گرا و مبتنی بر مؤلفه، احتمال موفقیت را افزایش می دهد.

6. الگوی توسعه تجزیه تحلیل سیستم های ساخت یافته (35)

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

گام ها و مراحل روش توسعه تجزیه تحلیل سیستم های ساخت یافته

در ادامه، به شرح جزئیات عملیات و کارکردها در هر گام از الگوی توسعه تجزیه تحلیل سیستم های ساخت یافته می پردازیم:

- امکان سنجی(38):

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

- بررسی محیط موجود (سیستم جاری)(40):

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

هم زمان با این کارها، نیازمندی های سیستم پیشنهادی شامل: سرویس های جاری و نیازمندی های مورد نیاز برای حل مشکلات کنونی، و همچنین محدودیت های پروژه، تحلیل و مستندسازی می شوند.

- گزینه های سیستم تجاری(43):

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

- تعریف نیازمندی ها:

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

- تحلیل گزینه های فنی سیستم(45):

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

- طراحی منطقی(46):

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

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

- طراحی فیزیکی(48):

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

7. روش حلزونی(49)

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

این روش، به مجموعه فعالیت هایی تقسیم می شود که به آنها «ناحیه های کاری»(51) می گوییم و بین سه تا شش ناحیه است. شکل ذیل، مدل شش ناحیه ای حلزونی را نشان می دهد و شرح کامل نواحی موجود در شکل نیز در ادامه خواهد آمد:

روش حلزونی

- ارتباط با مشتری(52): در این فاز، ارتباط و جلسات مؤثر بین توسعه دهنده و مشتری صورت می پذیرد که منجر به کشف چرایی و چیستی مسئله، تجزیه و تحلیل نیازها و بستن قراردادها می شود.

- برنامه ریزی(53): فعالیتهایی است که برای تعریف منابع، زمان ها، و اطلاعات دیگر مربوط به پروژه نیاز است؛ به عنوان مثال، تشکیل تیم های کاری و تعیین وظایف آنها، جزء این فعالیت ها می باشد.

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

- فاز مهندسی(55): فعالیت های لازم برای مهندسی و تولید و ساخت یک یا چند ارائه خاص از نرم افزار را پوشش می دهد.

- ساخت و انتشار(56): مجموعه فعالیت های لازم برای تولید، تست، نصب و تهیه مستندات آموزشی را شامل می شود.

- ارزیابی مشتری(57): فعالیت های لازم برای جمع آوری بازخوردهای مشتری بر اساس ارزیابی از نرم افزار در خلال مرحله مهندسی و پیاده سازی را پوشش می دهد.

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

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

8. مارپیچی بَرنده بَرنده(58)

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

در حالت واقعی، مشتری و سازنده وارد فرایند گفت وگو و بحث می شوند و در این فرایند ممکن است، از مشتری خواسته شود تا میان عملکرد، کارایی و ویژگی های دیگر سیستم یا محصول، در مقابل هزینه و زمان بازیابی، موازنه برقرار کند. در بهترین مباحثات، سعی می شود تا یک نتیجه «بُرد بُرد» حاصل شود؛ یعنی مشتری با دستیابی به محصول یا سیستمی که واجد بیشتر نیازهای اوست، برنده می شود و سازنده با کارکردن در چارچوب مهلت و بودجه ای واقعی و قابل حصول، برنده خواهد شد.

روش مارپیچی win win بوهم، مجموعه ای از اعمال مباحثاتی را در آغاز هر دور جدید از الگوی مارپیچی تعریف می کند. به جای یک عمل ارتباط با مشتری، اعمال ذیل انجام می شود:

• - شناسایی واگذارنده های کلیدی سیستم یا زیرسیستم ها؛
• - تعیین «شرایط بُرد» واگذارنده ها؛
• - بحث و گفت وگو درباره شرایط بُرد واگذارنده، برای مصالحه و توافق آنها در یک مجموعه شرایط بُرد بُرد، برای همه موارد مربوط (از جمله تیم پروژه نرم افزار).

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

نخستین نقطه لنگرگاهی که «اهداف چرخه حیات» نام دارد، برای فعالیت عمده در مهندسی نرم افزار، مجموعه ای از اهداف را تعیین می کند؛ برای مثال، به عنوان بخشی از اهداف چرخه حیات، یک مجموعه اهداف با تعریف خواسته های محصول/ سیستم سطح بالا همراه می شود. دومین نقطه لنگرگاهی که «معماری چرخه حیات» نام دارد، اهدافی را تعیین می کند که باید به موازات تعریف معماری سیستم و نرم افزار برآورده شوند.

برای مثال، به عنوان بخشی از معماری چرخه حیات، تیم پروژه نرم افزاری باید تشریح کند که موجودیت مؤلفه های آماده و قابل استفاده مجدد را ارزیابی کرده، تأثیر آنها را بر تصمیم گیری های معماری مد نظر قرار داده است. «قابلیت عملیاتی اوّلیه»، سومین نقطه لنگرگاهی است و مجموعه ای از اهداف است که عبارت اند از: آماده سازی نرم افزار جهت نصب/توزیع، آماده سازی پایگاه پیش از نصب، و کمک به تمام کسانی که نرم افزار را استفاده یا پشتیبانی می کنند.

9. مونتاژ مؤلفه ها(59)

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

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

روش مونتاژ مؤلفه ها

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

اگر کلاس مورد نظر وجود داشته باشد، استفاده مجدد می شود؛ وگرنه از نو ساخته می شود و طراحی و توسعه در تکرارهای مختلف بالغ تر شده و تکمیل می گردد. این روش، باعث می شود نرم افزارهای با قابلیت استفاده مجدد را با سرعت بالاتری تولید کنیم. برآوردها نشان می دهد که این مدل 70% زمان گسترش سیستم را کاهش می دهد. البته این نتایج به طور دقیق به استحکام مؤلفه ها وابستگی دارد. نرم افزارهای تولیدشده از طریق مدل، غالباً دارای کیفیت بالا می باشد و در محیط های کاربردی و عملی، قدرت پاسخگویی خوب و کارایی مناسبی دارند.

10. توسعه هم روند(61)

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

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

یک فعالیت، مثل فعالیت تجزیه و تحلیل، می تواند در هریک از وضعیت های ذکرشده باشد. به طور مشابه، فعالیت های دیگر مثل طراحی و ارتباط با مشتری، می توانند در حالتی مشابه ارائه شوند. تمام فعالیت ها به طور هم روند وجود دارند؛ ولی در حالت های مختلف قرار می گیرند؛ برای مثال، وقتی فعالیت ارتباط با مشتری، اوّلین دور خود را تمام می کند و در وضعیت انتظار تغییرات(63) می باشد، فعالیت تجزیه و تحلیل که در وضعیت none قرار دارد، به حالت تحت توسعه(64) می رود. اگر مشتری تغییری در نیازهای خود انجام دهد، فعالیت تجزیه و تحلیل به وضعیت انتظار تغییرات می رود. این روش، یکسری اتفاقات را که باعث تغییر وضعیت فعالیت ها از یک وضعیت به وضعیت دیگر می شوند، تعریف می نماید.

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

روش توسعه هم روند

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

11. روش های رسمی(67)

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

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

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

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

12. فنون نسل چهارم(69)

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

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

• - زبان های غیر رویه ای برای پرس وجوهای پایگاه داده؛
• - تولید گزارش؛
• - دست کاری داده؛
• - تولید کد؛
• - قابلیت گرافیک سطح بالا؛
• - قابلیت صفحه گسترده.

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

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

13. روش XP

روش(XP(71، از رده روش های مدل سازی چابک(72) است. این رده از الگوهای مدل سازی در مقابل رده مدل سازی روش های سنگین وزن(73) قرار می گیرند و با یکدیگر قابل مقایسه می باشند. مهم ترین خصوصیات الگوهای مدل سازی چابک، این است که این رده از الگوها که عموماً برای پروژه های کوچک به کار گرفته می شوند، بسیار انعطاف پذیر، تطابقی، مقرون به صرفه، اکتشافی و غیرقابل پیش بینی هستند.

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

14. روش CMM

روش تکامل قابلیت (Capability Maturity Model) که به اختصار CMM نامیده می شود، شیوه ای است که برای توسعه و تصحیح فرایند توسعه نرم افزار استفاده می گردد. این مدل، توسط مؤسسه مهندسی نرم افزار (SEI) که مؤسسه توسعه و تحقیق مورد حمایت ایالات متحده است، ایجاد شد. CMM، مشابه ایزو ۹۰۰۱ می باشد. ایزو ۹۰۰۱، به طور خاص با توسعه و نگهداری نرم افزار سروکار دارد. تفاوت اصلی میان این دو روش، در اهداف آنها نهفته است: ایزو ۹۰۰۱، سطح قابل پذیرشی از کیفیت را برای فرایند نرم افزار تعیین می کند؛ درحالی که سی.ام.ام چارچوبی را برای بهبود پیوسته فرایند فراهم می آورد و در تعریف و رسیدن به راهکارهای لازم، صریح تر می باشد.

پی نوشت ها: