دانلود مقاله درک مفهوم نرم افزار (و سرانجام درکی از مهندسی نرم افزار)

ویژگیهای نرم افزار
برای درک مفهوم نرم افزار (و سرانجام درکی از مهندسی نرم افزار)، بررسی آن دسته از ویژگیهای نرم افزار که آن را از دیگر چیزهای ساخته دست بشر متمایز می سازد، اهمیت دارد.

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

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

از این رو، نرم افزار دارای ویژگیهایی است که تفاوت چشمگیری با ویژگیهای سخت افزار دارند.
1.

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

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

هر دو عمل وابسته به انسان هستند، ولی رابطه میان انسان و کاری که انجام می شود، کاملاً متفاوت است (فصل 7).

هر د.

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

این بدان معناست که پروژه های نرم افزاری را نمی توان همانند پروژه های تولید معمولی مدیریت کرد.
2.

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

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

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

بنابراین، در تئوری، منحنی شکست برای نرم افزار باید شکل منحنی ایده آل شکل 2-1 را به خود بگیرد.

عیوب کشف نشده باعث آهنگ شکست شدید، در ابتدای عمر برنامه می شود.

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

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

ولی، معنای آن واضح است، نرم افزار هرگز دچار فرسایش نمی شود بلکه فاسد می شود!
این تناقض ظاهری را می توان با در نظر گرفتن ((منحنی واقعی)) به بهترین وجه توضیح داد (شکل 2-1).

نرم افزار در دوران حیات خود دستخوش تغییر می شود (نگهداری).

با اعمال این تغییرات، احتمال دارد که برخی عیوب جدید وارد شوند و باعث خیز منحنی آهنگ شکست شوند (شکل 2-1).

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

حداقل میزان شکست به آهستگی افزایش می یابد – نرم افزار در اثر تغییر فاسد می شود.
یک جنبۀ دیگر از فرسایش نیز اختلاف میان سخت افزار و نرم افزار را نشان می دهد.

هنگامی که یک قطعه از سخت افزار فرسوده می شود، با یک قطعه یدکی تعویض می شود.

ولی نرم افزار قطعات یدکی ندارد.

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

از این رو، نگهداری نرم افزار به مراتب پیچیده تر از نگهداری سخت افزار است.
3.

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

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

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

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

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

در جهان سخت افزار، استفاده مجدد از قطعات، بخشی طبیعی از فرآیند مهندسی است.

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

در دهۀ 1960، کتابخانه هایی از زیرروال های علمی ساختیم که در آرایۀ گسترده ای از کاربردهای مهندسی و علمی قابل استفاده بودند.

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

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

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

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

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

منظور از محتوا، معنی و شکل اطلاعات ورودی و خروجی است.

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

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

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

چنین کاربردهایی دارای قطعیت هستند.

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

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

با پیچیده تر شدن نرم افزار، مرزهای صریح و روشن، رنگ می بازند.

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

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

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

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

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

نرم افزارهای زمان حقیقی.

نرم افزاری که رویدادهای جهان واقع را همانطوری که رخ می دهند، نظارت / تحلیل / کنترل می کند، نرم افزار زمان حقیقی نامیده می شود.

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

نرم افزارهای تجاری.

پردازش اطلاعات تجاری گسترده ترین زمینۀ کاربرد نرم افزارها را تشکیل می دهد.

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

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

این نرم افزارها علاوه بر کاربردهای پردازش داده ها، شامل برنامه های کامپیوتری محاوره ای (نظیر پردازش تراکنش نقطۀ فروش) نیز می شود.

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

نرم افزارهای علمی توسط الگوریتم هایی مشخص می شوند که ((ارقام و اعداد)) را پردازش می کنند.

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

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

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

نرم افزارهای تعبیه شده.

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

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

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

نرم افزارهای کامپیوترهای شخصی.

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

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

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

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

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

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

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

سیستم های خبره، که سیستم های مبتنی بر آگاهی نیز نامیده می شوند؛ تشخیص الگوها (تصویری و صوتی)؛ شبکه های عصبی مصنوعی؛ اثبات قضایا و بازی، همگی مثالهایی از کاربرد این گروه هستند.

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

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

در بیان دانه کاربرد، حد و مرز باید مشخص باشد.

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

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

چون برآوردهای هزینه و زمانبندی، مبتنی بر عملیات هستند، غالباً قدری تجزیه، مفید واقع می شود.

ملاحظات کارآیی شامل خواسته های پردازشی و زمان پاسخ می شوند.

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

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

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

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

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

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

به هر حال، این ارتباط باید آغاز شود.

گاوز و واینبرگ [GAU89] پیشنهاد می کنند که تحلیلگر با پرسیدن سئوالات مستقل از مسئله شروع کند.

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

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

برای مثال، تحلیلگر ممکن است بپرسد: چه کسی پشت تقاضای این کار قرار دارد؟

چه کسی از حل این مسئله استفاده می کند؟

حسن اقتصادی یک حل موفق چیست؟

آیا منبع دیگری برای حل وجود دارد؟

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

این راه حل برای چه مسئله (هایی) مناسب است؟

آیا می توانید محیطی را که این راه حل در آن استفاده خواهد شد، به من نشان دهید (یا توصیف کنید)؟

آیا شرایط حدی یا مشکلات کاری خاصی وجود دارد که شیوه رسیدن به حل مسئله را تحت تأثیر قرار دهد؟

آخرین مجموعه سئوالات بر میزان کارآمدی نشست تأکید دارد.

گاوز و واینبرگ آنها را شبه سئوال می نامند و لیست (کوتاه شده) زیر را پیشنهاد می کنند: آیا شما شخص مناسب برای پاسخ دادن به این سئوالات هستید؟

آیا پاسخها ((رسمی)) هستند؟

آیا سئوالاتی که می پرسیم با مسئله شما ارتباط دارد؟

آیا زیاد سئوال می کنم؟

آیا کس دیگری هم هست که اطلاعات بیشتری بدهد؟

آیا مورد دیگری هست که از شما بپرسم؟

این سئوالات (و سئوالات دیگر) به شروع کار کمک کرده ارتباطی را که برای تعیین دامنۀ کاربرد پروژه ضروری است، آغاز می کند.

ولی قالب پرسش و پاسخ، روشی کاملاً موفق نیست.

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

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

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

تاریخ نشان داده است که این روش، نتایج ضعیفی در پی داشته است.

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

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

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

امکان سنجی هنگامی که دامنه کاربرد تعیین شد (با حضور مشتری)، منطقی است که بپرسیم: ((آیا می توان نرم افزاری ساخت که مناسب این دامنه کاربرد باشد؟

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

پوتنام و مایزر [PUT97a] این مشکل را چنین عنوان می کنند:...

هر چیز قابل تصوری، امکانپذیر نیست حتی در نرم افزار که در نظر افراد بیرونی ممکن است ناپایدار باشد.

برعکس، امکان پذیری نرم افزار چهار بعد دارد: فنّاوری – آیا پروژه از نظر فنی امکانپذیر هست؟

آیا می تواند پیشرفته باشد؟

آیا نقایص را می توان تا آن حد کاهش داد که با نیازهای کاربرد مورد نظر جور درآید؟

مالی – آیا از نظر مالی امکان پذیر هست؟

آیا می توان پروژه را با هزینه ای به پایان رساند که سازمان نرم افزاری، مشتری آن یا بازار از عهدۀ این هزینه برآید؟

زمان – آیا زمان تحویل محصول پروژه به بازار طوری هست که رقبا را از میدان به در کند؟

منابع – آیا سازمان دارای منابع لازم برای موفقیت هست؟

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

قبلاً پروژه های مشابه را انجام داده اید.

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

پروژه هایی که تاکنون تجربه نکرده اید، چندان آسان نیستند.

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

آیا برخی از این خواسته ها ریسکهایی را تحمیل می کنند که پروژه را امکانپذیر می کند؟

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

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

در همین حال، مدیران ارشد عصبانی می شوند.

غالباً با بی حوصلگی می گویند: ((کافی است، وظیفه تان را انجام دهید)).

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

پوتنام و مایزر به درستی پیشنهاد می کنند که تعیین دامنه کاربرد به تنهایی کافی نیست.

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

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

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

به عنوان مثال، نرم افزاری برای یک سیستم مرتب سازی خط نقاله (CLSS) را در نظر بگیرید.

بیان دامنه کاربرد CLSS به شرح زیر است: سیستم مرتب سازی خط نقاله (CLSS) جعبه هایی را که روی خط نقاله در حرکتند، مرتب می کند.

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

جعبه ها از یک ایستگاه مرتب سازی عبور می کنند که حاوی یک بارکدخوان و یک PC است.

PC ایستگاه مرتب سازی، به راهکاری متصل است که جعبه ها را به صندوقهای مناسب هدایت می کند.

جعبه ها با نظم تصادمی عبور می کنند و سرعت یکسان دارند.

سرعت خط، 5/1 متر در دقیقه است.

طرح کلی از CLSS در شکل 1-5 نشان داده شده است.

CLSS اطلاعات ورودی را از یک بارکد خوان و در بازه های زمانی مطابق با سرعت خط نقاله دریافت می کند.

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

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

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

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

نرم افزار CLSS همچنین ورودی حاصل از یک نانومتر (سرعت سنج) پالسی را دریافت می کند که برای همزمان سازی سیگنال کنترل با راهکار شنت به کار می رود.

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

برنامه ریز پروژه بیان دامنه کاربرد را مطالعه کرده همۀ عملیات نرم افزاری مهم را استخراج می کند.

این فرآیند که تجزیه نام دارد در فصل 3 بحث شد.

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

پردازش مربوط به هر جعبه باید پیش از رسیدن جعبۀ بعدی به بارکد خوان، به پایان برسد.

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

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

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

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

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

عملکرد، کارآیی و شرایط حدی ارتباطی تنگاتنگ دارند.

نرم افزار با عناصر دیگر سیستم کامپیوتری تعامل دارد.

برنامه ریز، ماهیت و پیچیدگی هر واسط را در نظرمی گیرد تا هر گونه اثر بر منابع، هزینه و زمانبندی توسعه را تعیین کند.

مفهوم واسط به معانی زیر تفسیر می شود: 1.

سخت افزار (مثل پردازنده و لوازم جانبی) که نرم افزار را اجرا می کند و دستگاههایی (مثل ماشینها و صفحات نمایش) که به طور غیرمستقیم توسط نرم افزار کنترل می شوند؛ 2.

نرم افزارهایی که از قبل موجودند (مثل روالهای دستیابی به بانک اطلاعاتی، مؤلفه های نرم افزاری قابل استفاده مجدد و سیستم عامل) و باید به نرم افزار جدید متصل شوند؛ 3.

افرادی که از طریق صفحه کلید یا دستگاههای I/O دیگر از نرم افزار استفاده می کنند؛ 4.

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

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

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

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

منابع دومین وظیفۀ برنامه ریزی برای نرم افزار، برآورد منابع لازم برای توسعۀ نرم افزار است.

شکل 2-5 منابع توسعه را به شکل یک هرم نشان می دهد.

محیط توسعه – ابزارهای سخت افزاری و نرم افزاری – در قاعدۀ هرم منابع قرار گرفته است و زیرساختی برای پشتیبانی توسعه فراهم می آورد.

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

در رأس هرم، منبع اصلی – افراد – قرار دارد.

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

دو ویژگی آخری را می توان به عنوان یک پنجره زمانی در نظر گرفت.

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

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

وضعیت سازمانی (مثلاً مدیر، مهندس نرم افزار ارشد و غیره) و تخصص (مثلاً ارتباطات راه دور، بانک اطلاعاتی، مشتری / کارگزار) مشخص می شوند.

برای پروژه های نسبتاً کوچک (یک نفر – سال یا کمتر) یک نفر می تواند همۀ مراحل مهندسی نرم افزار را اجرا کند که در صورت نیاز با متخصصان مشورت می کند.

تعداد افراد مورد نیاز برای یک پروژه نرم افزاری، فقط پس از برآوردکردن کار لازم برای توسعه (مثلاً برحسب نفر – ماه) قابل تعیین است.

تکنیک های برآورد کار را بعداً در همین فصل مورد بحث قرار می دهیم.

منابع نرم افزاری قابل استفاده مجدد مهندسی نرم افزار مبتنی بر مؤلفه ها (CBSE) بر قابلیت استفاده مجدد تأکید دارد – یعنی ایجاد و استفادۀ مجدد مؤلفه های سازنده [HOO91].

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

بناتان [BEN92] چهار دسته از منابع نرم افزاری را پیشنهاد می کند که با پیشرفت برنامه ریزی باید در نظر گرفته شوند: مؤلفه های آماده.

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

این مؤلفه ها که به اختصار COTS نامیده می شوند، برای پروژه فعلی قابل استفاده بوده به طور کامل اعتبارسنجی می شوند.

مؤلفه های تجربه کامل.

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

اعضای تیم نرم افزاری فعلی، در حیطۀ کاربرد ارائه شده توسط این مؤلفه ها تجربه کامل دارند.

لذا، اصلاحات مورد نیاز برای مؤلفه های تجربه کامل، ریسک نسبتاً پایینی دارد.

مؤلفه های تجربه ناقص.

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

اعضای تیم نرم افزاری فعلی در حیطۀ کاربرد این مؤلفه ها تجربه محدودی دارند از این رو، اصلاحات مورد نیاز برای مؤلفه های تجربه ناقص، دارای درجه بالایی از ریسک هستند.

مؤلفه های جدید.

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

هنگامی که مؤلفه های قابل استفادۀ مجدد به عنوان یک منبع در نظر گرفته می شوند، برنامه ریز نرم افزار باید دستورالعملهای زیر را مدّ نظر داشته باشد: اگر مؤلفه های آماده نیازهای پروژه را برآورده می سازند، آنها را به دست آورید.

هزینه به دست آوردن و سرهم کردن مؤلفه های آماده همواره کمتر از هزینۀ توسعه نرم افزار هم ارز است.

به علاوه درجۀ ریسک هم پایین است.

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

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

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

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

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

مؤلفه های نرم افزاری قابل استفاده مجدد، غالباً طی برنامه ریزی چشم پوشی می شوند تا در اثنای توسعۀ فرآیند نرم افزار مورد توجه قرار گیرند.

بهتر است خواسته های منابع در همان ابتدای کار مشخص شود.

به این ترتیب، ارزیابی فنی راههای دیگر قابل اجرا بوده به موقع می توان آنها را به دست آورد.

منابع محیطی محیطی که پروژۀ نرم افزاری را پشتیبانی می کند و غالباً محیط مهندسی نرم افزار (SEE) خوانده می شود، سخت افزار و نرم افزار را با یکدیگر همراه می سازد.

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

چون اکثر سازمانهای نرم افزاری دارای اجزای سازندۀ چندگانه ای هستند که نیازمند دستیابی به SEE هستند، برنامه ریز پروژه باید پنجرۀ زمانی مورد نیاز سخت افزار و نرم افزار را تجویز کند و تصدیق کند که این منابع در دسترس هستند.

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

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

همۀ عناصر سخت افزاری باید توسط برنامه ریز پروژۀ نرم افزاری مشخص شوند.

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

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

برای مثال، در سیستمهای سفارشی، خطای بزرگی در برآورد هزینه می تواند به اندازۀ تفاوت میان سود و زیان کار باشد.

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