software acquisition process

صفحه 1:
Software acquisition process 

صفحه 2:
در فصل يانزدهم كناب " ۵۴۷۵15 ۲۵۲۲۵6۵ 6511۳۵۲0۲5 6۵5۴" به دنبال تعریف و توضیح چندین متدلوژی کلیدی یادگیری و اکتساب نرم افزار یا همان «0انعن2 50۴۲۷۵۲۵ " " که در جهت تولید محصولات نرم افزاری ‎(software products)‏ 42 ابعاد انبوه که توسط دپارتمان صنایع دفاعی استفاده شده اند هستیم . در ابتدا بايد به اين سوال پرداخت که 0۲۵۵۵6۲5 50۴۷۷3۵۲6 چه مفهومی را در بردارد؟؟ محصولات نرم افزاری چیزی جز سیستم های نرم افزاری ارسال شده به مشتریان همراه با یک سری ! کاتالوگ ها در رابطه با نحوه راه اندازی و استفاده از آن ها نیستند . 7 8: 4 به هوهو ‎i‏ ‎re _. ric‏ 0 ‎IS‏ مشتری می تواند آن را ‎Ge‏ ‏انول محصولات زرم ‎cs oes‏ افزاری 8 © له ماوناه ۳ 5 251 زار وجود ندارد و صرفا جهت استفاده یک شرکت خاص طراحی شده است 

صفحه 3:
Generic Software vs Custom Software Custom Software Y More expensive Y Less reliable v Delay due to high development time © Less user friendly v Completely satisfied “Can easily accommodate future changes Generic Software “Less expensive ¥ More reliable v Immediate installation ¥ More user friendly v User requirements are not completely satisfied ¥ Cannot accommodate future changes 

صفحه 4:
حال به یادگیری مفهوم اکتساب نرم افزار(5.۵) می پردازیم می نوان آن را ساختاری شامل متدهایی در جهت تولید و توسعه محصولات نرم افزاری با در يط ركرفتن منابع مالی + ‎sla ris‏ مدیریتی و مهندسی +برنامه ریزی زمانی و ... در نظر رفت فراكيرى اين متدلوزى ها نقش تايين كننده اى در جهت تعيين تخمينى هزينه ها به صورت نرم افزارى ( نه به صورت سنتی) دارند . هر یک از بخش ‎cle‏ اين فصل نشان دهنده ی یکی از این متدهاست که شامل 1. آمادگی منابع کامپیوتری در جهت رفع انواع تقاضا 2 استفاده از وضعیت سنج ها(۱۳۱۵0[6۵10۳5 کلااها5) جهت ارزیابی فرایند توسعه نرم افزاری 3 ارزیابی و برآورد میزان پشتیبانی از محصول نرم افزاری می باشند . این متد ها با هم به کمک می کنند تا مطمتن شویم که نیاز ها ی سیستم قابل تامین شدن هستند یا خیر 

صفحه 5:
00 در راستاى رسيدن به يك نرم افزار قابل اطمينان و كارآ جندين و جند مانع وجود دارد كه به طور كلى مى توان به 1. توضيح مبهم نيازمندى ها 2غدم مديريت مناسب ذر جهت توسعه نرم افزار .بی توجهی به نست کردن برنامه در شرایط وافعی 4.جمع آوری ضعیف داده و اطلاعات بای تم رتکدااراشت هلت کافدیر قماگفرشی نز ملفزلی و حلوپر تخارین‌طنیای‌ها ‎dW‏ می باشند . مفاهیم زا در هر قدم از پیاده سازی نرم افزار به خوبی درک کرده باشند . چنین رفتاری سبب کاهش ریسک های نیاز مند پشتیبانی در بلند مدت می شود آن هم بدون اینکه هزینه های دست و پا گیری بر روی پروژه قرار دهد که از جمله این ریسک ها می توان به کمبود بودجه و تاخیر در تحویل نرم افزار و نگرش امن © © مدیریت توسعه ی نرم افزار بر اساس تجرییات گذشته همواره ثابت کرده است که © © وظیفه راحتی نیست به طوری که وجود هزینه های مازاد بر پیش بینی و عدم تطابی 897 پیشرفت با برنامه و مشکلات کیفیتی و... در وضعیت نرمال تر و بیش تری نسبت به انتظارات اولیه هستند .برای این مشکلات می توان علل زیادی نام برد ولی یکی از مهم ترین عیب ها و کاستی های مدیرتی را (که از جمله عوامل این مشکلات است) می توان به ناتواتی در شناخت مشکلات توسعه نرم افزار در ابتدای اشاره کرد . این مشکلات شناخته نشده به مرور زمان بیشتر و بیشتر در داخل نرم افزار نفوز 

صفحه 6:
Life cycle او کت بر عمر محصول است و به محص اینکه محصول برای فروش موجود باشد رخ می‌دهد. در اول ابن مرحلهء سود‌ها کم با غیرموجود هستند. اگر مرحله مقدماتی چرخه عمر محصول موفق باشد, این محصول به مرحله رشد منتقل خواهد شد. در اين نقطهء سود نیز افزايش خواهد یافت, زیرا هزینه‌های تولید و ارتقاء هر واحد قروخته شده کاهش می‌پابد. چالش برای کسب و کار این است که مرحله رشد چرخه عمر محصول را تاجایی که ممکن است طولانی بسازيم. این امر ممکن است شامل ارتقاء محصول یا ورود به بازارهای جدید باشد. در مرحله بلوغ از چرخه عمر محصول», سرعت فروش کاهش می‌یابد زیرا فروش محصولات به یک نقطه اوج رسیده است. در این مرحله از کسب و کار, استراتژی معرفی خواهد شد که تلاش می‌کند فروش‌ها را مانند کاهش قيمت‌ها و کمپین‌های تبلیغاتی اضافی افزایش دهد. چنین استراتژی گران است و احتمالا منجر به یک کاهد, :,, سودها برای پوشش هزینه‌های ارتقا می‌شود. این مرحله, مرحله نهایی از چرخه عمر محصول است. همانگونه که نام آن نشان می‌دهد در مرحله کاهش؛ فروش و سوددهی شروع به کاهش یافتن می‌کند. درطول مرحله کاهش, تولیدکننده محصول ممکن است تلاش کند برای تحریک رشد. استراتژی قیمت گذاری خود را تغییر دهد با این حال در اکثر موارد. اين تصميم نیاز به تغییر یا جایگزینی محصول دارد. 

صفحه 7:
V-SHAPED 

صفحه 8:
۷۱۷۵۲۵۲۲۵۱۱ مدل ابشاری را مى توان يك مدل بايه براى توسعه ات و در آن مراحل توليد به شكل يك جريان مداوم متمايل به سمت پایین است (همانند يك آبشار) كه شامل فازهاى تحليل خواستههاء طراحىء بيادسازى 11110161116118311013 > أزمودن و تست كردن يكبارجه سازى يا ‎integration‏ و دادن محصول به بازار می‌شود . 

صفحه 9:
این مدل برای چه کسانی مناسب است ؟؟ تیم هایی با ساختار صلب و غیر منعطف و نیاز جدی به ایجاد مستندات به دلیل ساختار صلب و زمان بندی غیر منعطف با برنامه ريزى اوليه » مدل فرآیند توسعه نرم افزار آیشاری در شرایطی بهتر عمل می کند که اهدافبه طور اساسی در طی زمان تغبیر نکنند به عبارتی این مدل بويا نيست . در عمل» مدل فرایند آبشاری برای سازمانهای بزرگ مناسبتر است چرن قبل از شروع پروژه نیاز به کاغذ بازی و تهیه مستندات مدون و . جامع در مورد کلیه خواسته ها و مشخصات اسکوپ پروژه دارند این مدل مناسب چه کسانی نیست؟؟ اگر محصول جدیدی رو آزمایش مي‌کنيم یا به بازخورد کاربر نیاز داریم ؛ یا می‌خواهیم در روند توسعه پویاتر باشیم استفاده از مدل فرآیند آبشاری توصیه نمی گردد 1 Reon een ee 

صفحه 10:
Spiral model مدل مارپیچی همچنین یکی از روش‌های توسعه سیستم‌ها استء که در حوزه فناوری اطلاعات مورد استفاده قرار می‌گیرد. خصوصیت کلیدی این مدل» امکان مدیریت ریسک» در مراحل مختلف چرخه تولید نرم‌افزار می‌باشد که مدل آبشاری فاقد آن است. اين مدل اغلب در پروژه‌های بزرگ و پیچیده تر مورد استفاده قرار می‌گیرد .این مدل در هر بار تکرار به ترتیب *6 کار را تکرار می کند 1.تعبین نیازمندیها ©.اناليز ريسك 0 تولید و توسعه نرم افزار ۰ . ارزیابی 1667311010 انجام شده و برنامه ریزی برای تکرار بعدی 

صفحه 11:
اس مدل برای چه کسانی مناسب است ؟؟ اتيم هاى ريسك گریز که روی پروژه های بزرگ کار می‌کنند همجنين اكر مشترى كاملاً از خواسته هاى نرم افزار مطمئن نباشد و نتظار اعمال ویرایش های عمده در طول فرايند توسعه داشته باشد. این مدل مناسب است مدل فرایند حلزونی برای چه کسانی مناسب نیست؟ شرکت های انجام دهنده ی کارهای روتین و بی تمایل به یوس مزایا 0.كاهش ريسك شكست ©. بودجه مى تواند هر مرحله تغيير كند. ©.در همان ابتدا محصولى براى نشان دادن هست و نياز به صبر كردن تا اخر بروذه نيستيم معايب ).فهم ان نسبت به ابشارى سخت تر است 9. بسته به نوع پروژه می تواند واقعا هزینه بار شود 

صفحه 12:
‎=I)‏ ات رتش ‏ای کر ده ار عدل انشاری اس که بررگترین عیب آن بعنی عدم انجام آزمایش: به موقع از بازخورد مشتری را رقع می کند . ‏وی شکل ‎(Reavieenents) =‏ ‎C=‏ ‏— ‎Cz‏ ‎7 ‎shaped ‏مدل فرایند توسعه وی شکل فقط روی پروژه های کوچیک جواب داده و به درد پروژه های بزرگ نمی‌خورد . ‎۱ 

صفحه 13:
این مدل برای چه کسانی مناسب است ؟؟ تیم هایی که روی پروژه های کوچیک با محدوده و اسکوپ مشخص کار می‌کنند. این مدل مناست چه‌ کسانی نیست؟؟ تيمهايى كه مى خواهند انعطاف يذ شترى داشته باشد ان از خ تیمهایی مى خوا پذیری بیشتری داشته باشند و به دنبال ورودى و بازخورد كاربران در اولين زمان ممكن ‎eo oe‏ ساختار صلب و برلام آزمایش فشرده و غیر منعطف کنترل کمی روی فرایند وجود داره. همچنین از اونجا که ورودی و بازخورد زودهنگامی از طرف کاربران دریافت نمی‌کنید هنوز خطر ساختن نرم افزار اشتباهی وجود داره ‎ 

صفحه 14:
توسعه نرم افزار نیازمند کنترل مداوم است برای اطمینان از 9 مورد : 0 _نیازمندی های منعقد شده طبق قرار داد تامین شوند ‎as‏ افزار در حال توسعه به خوبی در آینده قابل پشتیبانی باشد ‏موثر ترین روش کنترل توسعه نرم افزاری نیازمند مجموعه ای از وضعیت سنج ها و ارزیابی های ارائه شده توسط آنهاست . این وضعیت سنج ها بايد بارخوردهای به موفع از توسعه را در اختیار قرار دهند که با تعریف نیازمندی ها شروع شده و با تلاش در جهت توسعه سیستم نرم افزاری ادامه می یبد . هم چنین منظور از به موقع بودن آن است که درگیر کردن توسعه دهنده با گزارشات مداوم از ارزیابی حالت سیستم و نیازمندی های موچود تالیری در افزایش کیفیت و یا کاهش هزینه ها نخواهد داشت و بیشتر ذهن آنها با اطلاعات تکراری در گر می گردد . ‏قابل پشتیبانی بردن سیستم نرم افزاری یک از دغدغه های هر شرکت و مشتری استفادهکننده از آن است . سیستم هایی با پشتیبانی ضعیف نیازمند هزینه های بالای نگهداری هستند و بر طبق تجارب مایل و مستعد به داشتن عملکرد ضعیف تر . کیفیت تولیدی پیین تر و اطمینان پذیری کمتری هستند .با توجه به حجم هزینه های چرخه عمر در فاز " ‎postdeployment‏ " داشتن پشتیبانی خوب ضروری است .از عوام تاثیر گذار بر پشتیبانی میتوان به ‏نوع طراحی سیستم 6. سطح تخصص اراد توسعه دهنده 6. زبان های نرم افزار 6۶. سطح کامل بودن اسناد و مدارک ‎s9 (documentation)‏ اشاره کرد. ‎ 

صفحه 15:
Request for proposal ابزاری استاندارد برای خریداری خدمات است که به صورت رسمی توسط سازمان تهیه می شود و به ارائه دهندگان خدمات مورد نظر ارائه می شود تا سازمان پیشنهاد ها و راه حل های مختلفی را برای یک موضوع واحد در اختبار داشته باشد و با دقت بیشتری به بررسی ان بپردازد. زمانی که یک شرکت قصد دارد یک پروژه داخلی انجام دهد یا پروژه ای را به منابع بیرونی سازمان ارجاع دهد به پیمانکار نیازپیدا می کند شرکت برای برگزاری مناقصه و جمع آوری پیشنهادات پیمانکاران مختلف باید درخواست طرح پیشنهادی خود را تهیه کنند . به شركث ها کمک می کند به تشریح جزییات مورد نظر و نیاز خود در اسناد مناقصه بپردازند و از اين طریق بتوانندبهترین پیمانکار را شناسایی نمایند. هیچگونه استاندارد مشخصی برای تهیه وجود ندارد اما نهاد های دولتی معمولاً چهارچوب هایی را برای هدایت کردن مسیر طرح های پیشنهادی اعمال می کنند. مزایا 1 کاهش شکایات احتمالی کارفرمایان و پیماتکاران 2 كيك به تنظيم قرارداد بهت 3. امكان مقايسه بين شركت هاى مختلف ارائه دهنده ى خدمات مشابه 4. افزايش توان مدير بروزه 

صفحه 16:
‎a as) ied‏ ها اب هی بسا ب هل ‎tin‏ و مر ی درب ‎ ‎Ae ee‏ سل توت ‎ ‎aw Gi Po Fp a I ae‏ جهت ‎GE PEA Id IE‏ دم ١_صنعت‏ اكنون جه لاش هاي بك وفع ين باز نجام دده است؟ دلايل عدم حل ككمل جالش جبست؟. عاك ‎ae TO ome‏ متقاضي ورهر مله دوه ۰۰ ی بر شور مع لهل لد ود كله دب جنوه ی یر وت وق ره ار مت مه و ی ‎EXAMPLE‏ ی ‎For‏ ‎ae a Ra aE A ۹۹‏ سس ‏| ند سوه جر هد مه ی لد سمد در وی مک سول نیت ‎ ‎ ‏|7 02017 0ع عي رمس ما تم متسین ریت زرد کر مهد ی وت موه ای ود یت نمدا وك ند ‎ ‏لت ۳ ‏ماع ۳ تشم ها نکم شوت هر تا هی شوت ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ 

صفحه 17:
Statement of work کار یا همان (0.۷.:) یک رسمى كه فعاليت هاى كارى واقلا جد ‎schedule) Le‏ ‎TET Par OS PRIRG See Ce pel pe Ges‏ در بیش تر موارد شرح کار یک فرار داد الزام اور است . هدف اصلی این است که مسئولیت ها» توافق های انجام شده بین دو طرف به دقت و با جزئیات تشریح شده بانشد تا در موافع نیاز به این قرارداد مراجعه شود - این است که تعریف می کند دقیفا زمینه کاری پروژه چه چیزی است و چه مواردی برای کافرما باید در چه زمانی و به چه شکل انجام شود . ‎Ne 7‏ ‎{i { 1‏ 

صفحه 18:
17 هدف (۳۷۲۴۵56): چرا ما اين پروژه را انجام می‌دهیم؟ اين سوالی است که پاراگراف هدف برای پاسخ به آن تلاش می‌کند. مجدوده ‎als‏ 51 60 نوه ‎ce orgs eine:‏ 3 كاري أن ست که باید به صورت دقیق انجام شود و مشخص‌کننده سخت‌فزار و نرم‌افزا ° زمان‌بندی اقلام تحویلی (16ن56060 0611۷۵۲۵9165): اين بخش فهرستی از اقلام تحویلی خاص و علت و زمان آن را توضیح مید wl 5 ‏رود هما‎ |, Lo j onus, id of rf ‏سا که ریب ام سس تب و ات‎ ee (period of Bertormancs) aS eve ee ey 423 ‏آن‌بندی شود.‎ 

صفحه 19:
‎Project Tite: Reclaimed Water Booster Pump Station (North-South‏ 1 كلع لتمكط ‎Interconnect Pipes under Livingston Road)‏ ‎A Introduction/Background ‎Collier County reused approximately 5 billion gallons of treated wastewater in 2004. The majority of the water is used by commercial and residential users for irrigation. Collier County also uses reciaimed water for irrigation at various parks and roadway medians. A small portion of tne reclaimed water is used for environmental mitigation. The reciaimed water system is made up of ‘over 50 miles of distribution piping, 130 million gallons of wet weather storage, two deep injection wells, and six large pumping stations. ‎The County serves two reciaimed water service areas referred to as the South and North service areas. The South service area is primarily served by treated effluent from the Soutn County Water Reclamation Facility (WRF) and the North service area is served by the Nortn Gounty WRF. The main issue Collier County's reclaimed water program faces is wet weather storage. ‎‘The County has identified a need to construct an in-line booster pump station to add flexibility and 2۵6 Increase efficiency to their reciaimed water system. The reciaimed water pump station wi ‎enhance the interconnections of the North and Soutn reclaimed water service areas, allowing the ‘County to serve as many customers as possible and also maximizing the use of their reclaimed ‎ ‎water storage facilities, including the reclaimed water ASR system, located in the North service area. 8 Objectives ‎This project will allow storage of reclaimed water during the wet season, providing additional reclaimed water during the peak demand. The project will consist of two phases: Phase 1 is to connect the North and Soutn reciaimed water service areas by microtunneling under the Livingston Road; Phase 2 is to build a reclaimed water booster pumping station. ‎ ‎c Scope of Work ‎FY2007 work activities include Phase 1: the microtunneling of two 16-inch reclaimed water mains across. Livingston Roac. ‎ 

صفحه 20:
Software development status indicator همانطور که بر همگان واضح است داشتن ارزیابی از وضعیت نرم افزار در حین ایجاد و توسعه آن یک نیاز ضروری است . اعمال اصلاحی ات مدیریتی ‎kee aig?‏ وايستكى غيرقابل جشم بوشى اك به ارزيابى هاى دقيق از وضعیت کنونی سیستم دارند . بنابرین می توان گف خواسته ی هر مدیر و توسعه دهنده ای مبنی بر داشتن مجموعه ای از . وضعیت سنج ها برای ارزیابی سیستم و ادامه ی حیات آن باید براورده شود 

صفحه 21:
مجموعه وضعیت سنج های نرم افزاری از سه رنگ (قرمز)+(کهربایی)+(سبز) تشکیل شده اند تا به راحتی ‎sly‏ همگان وضعیت سیستم قابل درک باشد . 8:۳۰ 7 ‏دا 0 رتنس‎ ۳ | GREENJAMBER] RED_| Feaunenenrsstasuny 01 PeveLopment manpower | | [J Pevetorment pRocRess [| COMPUTER REEEEe UMICZATION ‏اق ا‎ 7 521250255629155 | -*¥ 1774 frouate neronrresowuTion | & {7 Proouctoeuvery S| ۲:7۳:۳7 

صفحه 22:
uti اس نف ‘UTILIZATION 6 4 ۵ ا Figure 15.10. Conyarter resommee utilization chart Red: Resource utilization greater than 70% of builtin capacity Amber: Resource uthzation greater than 50% of builtin capacity but less than 7026 Resource utilization less than or equal te 50% 

صفحه 23:
22 داشتن ارزیابی از قابیلت پشتیبانی سیستم نرم افزاری بعد از انتشار نرم افزار افزار یا به هنگام عرضه آپدیت در فاز توسعه یک بخش مهم و ضروری است . ‎yt GIy eal pase eae Ay Ae Ales‏ هرز رسكم درم لوزن وا م كن لد بسا لین ‎ups dar El‏ منطقی است(0651۲2016 ). یک مدل ارزیابی برای کمک به پیاده سازی این فرایند که پیش نیاز های کلیدی برای قابلیت پشتیبانی نرم افزار در فاز توسعه را نشان می دهد وجود دارد که ار 49 فاکتور تشکیل شده است . 

صفحه 24:
Green Amber 5 7 Red 2 2 ۴ 3 ع ‎a‏ ‏2 ‏3 ‏5 ‏8 ‏ع ‏5 ‏8 excellent good fair poor Less than 60: unacceptable (not reasonably supportable) The system can also be judged not reasonably supportable if any of the following individual conditions exist: a. More than 85% of any subsystem memory is utilized. b. More than 85% of any subsystem throughput is utilized. 

صفحه 25:
Pz تعریف درست زیرسیستم ها یک قدم کلیدی در محاسبه ی قبلت پشتیبانی سیستم است . زیر سیستم های تعریف شده در محتواى توليد و كسترش نرم افزار ها به طور کلی همانندسایر زیر سیستم ها نیستند و تشکیل شده از مجموعه ای از کد ها می باشند . سه مشخصه اصلی زیر سیستم های نرم افزاری عبازتند یل . باقی فاکتور ها و مشخصات زير سیستم از الویت کمتری برخوردار هستند و زمانی تعریف می گردند که بخواهیم ساختار زیرسیستم ها را بیشتر مشخص کنیم 

صفحه 26:
COnstructive-COst model نت۳ تخمین هزینه های نرم افزاری بر پایه تعداد کد های نوشته متدی برای ت شده درهر هرار د((0 110 

صفحه 27:
a Project Estimation -« COCOMO Mode! Software Engineering ent Ai BASIC COCOMO MODEL itestates the software roughly and quickly. It's mostly useful for small - medium sized software ‎(K100)5 ۸‏ 1 = جه ‎¢ (Effort)4 ۸ 0۳53 ~ Effort Development Time re KLOC / Effort / ۷۷ ‎ ‎ ‎Type a b ¢ d Organic 24 1,05 25 0.38 Semi-detached 3.0 112 035 ‎ ‎Embeded 3.6 1.20 ‎ 

صفحه 28:
1 6 1 2 Project Estimation -COCOMO Mode! Software Engineering {BY Gn 0062400 8224 b=105 c=25 8 ی ۲ 60050 2.4 (400) 1.95 Per ‎c (Effort) 4 Mont‏ سس با ‎2,5 (1295) 9-38 ‎ ‎ 

صفحه 29:
2 6 ‏كم‎ Project Estimation - COCOMO Mode! _ Software Engineering PASC ۵۵-400 223 b=112 c=25 25 GREED ~ 0 Month 3 )400(1.12 ۵ 2462 Person-l ‎Months‏ 4 ۱۳ سس ‎2.5 (2462) 9.35 ‎38.4 M ‎ 

صفحه 30:
3 4 Project Estimation - COCOMO Mode! — software Engineering (3 1 (0 | ۵6-4۹00 8236 ۵21۵ 0225 2 a (KLOC) 3.6 (400) 1.2 4772 2) 0. 32 ۱ 

صفحه 31: