مدیریت پروژه

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

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

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

تاریخچه مدیریت پروژه

مدیریت پروژه در زمینه های گوناگون کاربردی شامل ساختمان سازی،مهندسی ودفاعی گسترش یافته است. در ایالات متحده امریکا،پدر مدیریت پروژه، هنری گانت (Henry Gant)است که به عنوان پدر علم برنامه ریزی وروشهای کنترل نیز شناخته شده است. شهرت او به چند عامل بستگی داشته است: اول به خاطر استفاده از گانت چارت که یکی از ابزارهای کنترل پروژه محسوب می شود .دوم به خاطر همکاری با Fredrick Winslow Taylor در تئوری علمی مدیریت ودر نهایت شهرت او به علت مطالعاتش بر روی کار ومدیریت ساختمان کشتی نیروی دریائی بوده است.او در بسیاری از موارد از جمله استفاده از ساختار دسته بندی کسب وکار(WBS)وهمچنین تخصیص منابع پیشگام بوده است.

سالهای 1950به عنوان شروع مدیریت پروژه جدید شناخته شده است. در امریکا در اوایل سال 1950 پروژه ها غالبا به طور خاص براساس گانت چارت وبا روشها وابزارهای غیر رسمی مدیریت می شدند. درآن زمان دو مدل ریاضی برای جدول زمان بندی وجود داشت: 1-فن ارزیابی و بازنگری برنامه یا PERT (Program Evaluation and Review Technique ) که توسط Booz-Alen وHamilton ابداع شد.

2-روش مسیر بحرانی(CPM )Critical Path Method

این روش با مشارکت دو انجمن Du Pont وRemington Rand به منظور مدیریت پروژه های تعمیر ونگهداری طراحی شد.این روشهای ریاضی به سرعت در بسیاری از شرکتهای خصوصی گسترش یافت. در همان زمان روشهای برآورد قیمت تمام شده،مدیریت هزینه واقتصاد مهندسی توسط Hans Lang ودیگران در حال گسترش بود. درسال1965،انجمن مهندسین هزینه امریکا (که در حال حاضرانجمن بین المللی AACEمی باشد وهدفش پیشبرد علم مهندسی هزینه است)توسط اولین کاربران مدیریت پروژه وانجمن متخصصین برنامه ریزی وبرنامه زمان بندی،برآورد هزینه وکنترل زمان-هزینه تأسیس شد.AACE فعالیتهایش را ادامه داد ودرسال 2006اولین وکاملترین روش برایPORTFOLIO(اوراق بهادار)وبرنامه ریزی ومدیریت پروژه را منتشر کرد.(ساختار کامل مدیریت هزینه) در سال 1969،انستیتو مدیریت پروژهPMI)) به منظور سرویس دهی به صنعت مدیریت پروژه تشکیل گردید.فرضیه PMIاین است که علیرغم کاربردهای گسترده مدیریت پروژه در حوزه های مختلف از پروژه های صنعت نرم افزاری گرفته تا صنعت ساختمان سازی ابزار وروشهای آن مشترک هستند. در سال1981،PMI تصمیم گرفت که یک کتابچه راهنما برای شناخت مدیریت پروژه (راهنمای PMBOK)منتشر کند این کتابچه شامل استانداردها وراهنمائی های عملی است که در بحث های تخصصی کاربرد فراوانی دارد. در سال 1967،انجمن بین المللی مدیریت پروژه IPMA در اروپا تأسیس شد وآن هم به نوبه خود دستخوش تحولات وپیشرفت هائی گردید و انجمن ICB( Competence Baceline Institute)را تأسیس کرد.تاکید این انجمن بر روی تجارب قابل اعتماد،مهارت های شخصیو تشخیص صلاحیت می باشد.هر دوی این انجمن ها در حال حاضر در تهیه وتنظیم استاندارد ISO برای مدیریت پروژه می باشند.

 تعاریف

PMBOK( که به عنوان انستیتو مدیریت پروژه می باشد)مدیریت پروژه را این گونه تعریف می نماید:مدیریت پروژه ابزاری برای شناخت ،مهارت وروش های فنی است تا فعالیتهای پروژه را به نیازهای اصلی (اهداف)پروژه برساند. PRINCE2برنامه ریزی،نظارت وکنترل همه جانبه پروژه وبرانگیختن تمام افراد مرتبط با پروژه به منظور موفقیت پروژه یعنی دست یابی به اهداف پروژه در زمان مشخص ،باقیمت مشخص،کیفیت مشخص وراندمان مشخص PROJECTپروژه یک کار موقتی با تاریخ خاتمه مشخص است که به منظور ایجاد یک محصول منحصر به فرد ویا خدمات مشخص انجام می شود- هدف از اجرای پروژه برآورده کردن ایده ها ویانیازها می باشد DIN69901(سازمان آلمانی جهت استاندارد سازی) مدیریت پروژه یک سری وظائف کامل ،روش ها وابزاری است که در طی اجرای پروژه به کار گرفته می شود.

 تعریف کار

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

 محدودیتهای سه گانه وسنتی

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

 مثلث مدیریت پروژه

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

 

زمان

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

 هزینه

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

 کنترل متغیرهای پروژه

مدیریت پروژه می کوشد تا بر متغیرهای پروژه مانند ریسک غلبه پیداکند ویا آنهارا مهار کند.

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

 دیدگاهها

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

 دید گاه سنتی

دیدگاه سنتی 5 مرحله پشت سرهم را برای تکمیل پروژه ضروری می داند.در این دیدگاه لازم است ابتدا 5 مولفه یک پروژه (4 فاز +مرحله کنترل)را در مراحل پیشرفت پروژه تشخیص دهیم. 1- مرحله اولیه پروژه 2- برنامه ریزی یا فاز طراحی 3- اجرای پروژه یا فاز اجرائی 4- نظارت پروژه وسیستم های کنترل 5- فاز تکمیل پروژه لازم به ذکر است که نیازی نیست در همه پروژه ها این 5 مرحله به اتمام برسد. مثلاً در بعضی پروژه ها ممکن است فاز برنامه ریزی ویا نظارت وجود نداشته باشد ودر بعضی پروژه ها مراحل 2و3و4 چندین بار تکرار شود. در خیلی از صنایع از این چند مرحله استفاده می کنند. به طور مثال در طراحی معماری با مصالح بنائی (آجر وملات) پروژه ها از مراحلی چون پیش طراحی، طراحی تصوری (ادراکی)،طراحی شماتیک، طراحی توسعه ونقشه کشی ساختمان و... استفاده می کنند. در نرم افزارهای توسعه،این دیدگاه غالبا به عنوان آبشار توسعه شناخته می شوند.

 مختصری در باره Enterprise Project Management 2007

شرکت Microsoft در راستاي تکميل و توسعه قابليت هاي نرم افزار MS Project و به منظور ارائه يک راه‌حل جامع مديريت پروژه به مشتريان مجموعه محصولات نرم افزاري را به همراه چارچوب پياده سازي آنهاEIF(Enterprise Implementation Framework) در سازمان ها ارائه داده است. اين خانواده محصولات نرم افزاري شامل موارد زير هستند:

‎

• Microsoft Project Professional 2007
• Microsoft Project Server 2007
• Microsoft Project Web Access 2007
• Microsoft Sharepoint Services 2007
• Microsoft SQL server and Analysis services 2007
• Microsoft Project Portfolio Server 2007

براي همه سازمان هايي که MS Project را به دليل کاربر پسند بودن، سهولت استفاده و قابليت هاي يکپارچگي با مجموعه Office براي پاسخگويي به نياز برنامه ريزي و کنترل پروژه انتخاب کرده­اند و به دنبال توسعه همکاري اطلاعاتي تيم پروژه، کنترل مدارک پروژه و مديريت قوي­تر منابع و گزارش­گيري ساده­تر و سريع تر از وضعيت پروژه­هايشان هستند راه حل جامع مديريت پروژه EPM راه حل ايده­آل و قابل اعتماديست که کاهش ريسک پروژه و افزايش بازگشت سرمايه (ROI) را به همراه خواهد داشت.

 منابع

[سایت مدیریت پروژه ایران]http://www.iranpm.com

[مقالات مدیریت پروژه بتسا]http://www.betsa.ir/Cat/15.aspx

پیاده سازی راهکار مدیریت پروژه جامع EPM

آموزش Project Server

ویکی پدیا

خلاصه ای از قسمت ها مهم درس

خلاصه اي از مباحث ارائه شده

 

تعريف نرم افزار

 

·        نرم افزار از ديد مشتري محصولي است که نياز مشتري را برآورده مي کند.

·        نرم افزار از ديد مهندس نرم افزار :

1- برنامه کامپيوتري (کد اجرايي) که عمل به خصوصي را انجام مي دهد.

2- ساختار دادهاي که باعث مي شود دستورالعمل ها به شکل مناسبي با داده ها کار کنند.

3- مستنداتي که مشخصات نرم افزار و چگونگي پياده سازي و نحوه عمليات و چگونگي استفاده از نرم افزار را شرح مي دهد.

 

انواع نرم افزار

•        نرم افزارهاي سيستمي

•        نرم افزارهاي بلادرنگ ( real time )

•        نرم افزارهاي تجاري

•        نرم افزارهاي علمي مهندسي

•        نرم افزار هاي PC  

•        نرم افزارهاي تعبيه شده ( embedded  )

•        نرم افزارهاي مبتني بر web  

•        نرم افزارهاي هوشمند

•        نرم افزارهاي سيستمي

 

تعريف متدولوژي

•        يک متدولوژي مجموعه اي از روش ها  و توصيه ها (guidelines) مي باشد که به همراه راهبرد مشخص و طي مراحل مختلف از توسعه سيستم به کار گرفته مي شود. يک متدلوژي داراي ابزار تعريف شده و مدل مفهومي مي باشد و از يک گرامر مشخص استفاده مي کند.

•         براي مثال مدل شي گرا و يا مدل ساخت يافته در توسعه نرم افزار دو متدولوژي توسعه نرم افزار هستند.

 

تعريف مدل فرآيند

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

•        مدل فرآيند نرم افزار قدم ها و استراتژي توسعه نرم افزار فرآيند و روش مي باشد.

•        براي مثال مدل آبشاري و مدل حلزوني دو مدل فرآيند توسعه نرم افزار هستند

 

تفاوت هاي متدولوژي و مدل فرآيند

•        متدولوژي، روش طي کردن قدم هايي است که مدل فرآيند تعريف مي کند.

•        تکنولوژي مهندسي نرم افزار يک تکنولوژي لايه اي است و متدولوژي بروي لايه فرآيند قرار دارد.

 

  بررسي life cycle  توسعه نرم افزار

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

•        Life cycle  يک نرم افزار شامل تمام فعاليت هاي پيش از توليد ، توسعه و دوره اجراي نرم افزار است. 

 

بررسي life cycle  (پيش از توليد)

براي شروع پروژه، RFP  (Request For Proposal)به تيم نرم افزاري ارائه ميشود و تيم توسعه براي دريافت پروژه پيشنهاد خود را در قالب Proposal   ارائه ميکند.

 

 Managing Software Projects

 

 

•       بعدهاي مديريت

»       افراد (people)

»       محصول(product)

»       فرآيند (process)

»       پروژه (project)

»       اصول W5HH

 

 

افراد (People)

 •        فرآيند توسعه نرم افزار توسط نقشهاي زير اجرا ميشود :

•        مدير اصلي (senior manager)

•        مدير فني پروژه ( project technical manager)

•        کارکنان( practitioners)

•        مشتريان

•        کاربر نهايي

 

•       رهبر تيم

وظايف مديري که رهبري يک پروژه را بر عهده دارد عبارت است از  :

1)    تشويق

2)    نظم دهي

3)    ارائه ايده ها و نوآوري

4)    حل مسائل

5)    انجام تشخيص هاي مدريتي

6)    کنترل دستيابي به اهداف

7)    تشکيل و تاثير گذاري بر تيم

 

·        تيم هاي نرم افزاري

ساختار مناسب براي يک تيم بستگي به نوع سازمان، تعداد افراد، توانايي هاي اعضاي تيم ها و نوع و سختي کار دارد.

–        تيم هاي دموکراتيک ِ غير متمرکز (DD)

–        تيم هاي تحت کنترل غير متمرکز (CD)

–        تيم هاي کنترل شده متمرکز(CC)

 

4 نوع دسته بندي سازمان ها

1)    مدل بسته (close paradigm) : داراي ساختارهاي سنتي (شبيه CC)

2)    مدل تصادفي(random paradigm) : تيم بر افراد و نوآوري آنها تکيه دارد.

3)    مدل باز (open paradigm) : سعي ميکند خصوصيات نوع بسته و نوع تصادفي را دارا باشد.

4)    مدل همگام (synchronous paradigm) : بر تقسيم کار بين افراد تيم تاکيد دارد.

 

ارتباط ميان اعضاي تيم ها

•        تکنيک هاي همکاري و ارتباط در پروژه ها :

–        روشهاي رسمي و غير شخصي : شامل بر مستندات مهندسي نرم افزار، برنامه هاي پروژه و گزارشهاي موجود

–        رسمي و بين اشخاص: تمرکز بر فعاليت هاي QA  دارد مانند : جلسات بازبيني و مرور

–        غير رسمي و بين اشخاص : جلسات گروهي براي بحث و تبادل نظر و حل مسائل

–        ارتباطات الکترونيکي : مانند پست الکترونيک، بولتن هاي الکترونيک، ويدئو کنفرانس و ..

–        گردهمايي هاي بين افراد : شامل بر بحث هاي غير رسمي ميان افراد گروه و افراد خارج از پروژه

 

بررسي تکنيک هاي همکاري و ارتباط

  

محصول(Product)

 •        محدوده نرم افزار  (scope) : يکي از ابتدايي ترين فعاليتهاي مديريت پروژه، تشخيص محدوده محصول است. محدوده با پاسخ به سوالات زير در رابطه با نرم افزار به دست مي آيد.

–        مفهوم

–        اهداف اطلاعات

–        وظايف و کارايي

•        تجزيه مسئله (problem decomposing) : اين فعاليت يک فعاليت پايه در آناليز سيستم است.

 

•        فرآيند تعريف، توسعه و پشتيباني در توسعه تمامي سيستم هاي نرم افزار مشترک هستند. مسئله انتخاب يک مدل فرآيند مناسب با پروژه مربوطه  است.

•        مدير پروژه بايد در رابطه با مدل فرآيند توسعه پروژه تصميم گيري نمايد.

  

پروژه(Project)

•        براي مديريت موفق پروژه هاي نرم افزاري بايد متوجه شويم که چه مسائلي به درستي پيش رفته و کدام يک نا مطلوب پيش رفته اند.

•         تعدادي از نشانه هاي ظهور مخاطره در پروژه هاي نرم افزاري :

–        اعضاي تيم توسعه نيازهاي مشتري را درک نکنند.

–        محدوده محصول به درستي تعريف نشده باشد.

–        تغييرات به درستي کنترل نشوند و ...

 

 

اصول W5HH

•        7 سوال که “بوهم” براي يافتن اهداف و خصوصيات پروژه طرح نموده است :

–        Why is the system being developed ?

چرا سيستم بايد توليد شود؟

–        What will be done , by when?

چه کاري و تا چه زماني بايد انجام شود؟

–        Who is responsible for a function ?  

چه کسي مسئول يک وظيفه است؟

–        Where are they organizationally located ?

آنها ( اعضاي تيم توسعه) در چه محلي مستقر و ساماندهي شده اند ؟

–        How will the job be done technically and managerially ?

کارها از نظر فني و مديريتي چگونه انجام خواهند شد؟

–        How much of each resource is needed ?

چه مقدار از هر منبعي مورد نياز مي باشد ؟

 

 

معيارهاي اندازه گيري پروژه و فرآيند

Measure ، Metric  و indicator

 

هر چند ترم هاي  measure  ( اندازه) و metric  (معيار)  غالبا به جاي يکديگر به کار مي روند بايد توجه داشت که با يکديگر تفاوت دارند.

•        Measure  يک شاخص کمي از اندازه، مقدار، ابعاد و ظرفيت يک صفت از يک محصول يا فرآنيد را تعيين مي کند.

•        Metric  يک اندازه کمي از درجه اي به يک فرآيند، مولفه، سيستم براي يک صفت مشخص مي باشد.

•        Indicator  نوعي نشانه و شاخص براي شناخت روند حرکت تيم  و پروژه ميباشد.

 

معيارها در حوزه فرآيند و پروژه

•            اندازه گيري يکي از ابتدايي ترين اعمال در مهندسي است.

•            اما در دنياي مهندسي نرم افزار توافق دقيقي بروي آنکه چه بايد اندازه گيري شود و چگونه اندازه گيري شود وجود ندارد.

•            تنها راه منطقي براي براي بهبود هر فرآيندي، اندازه گيري خصوصيات مشخصي از فرآيند و توسعه مجموعه اي از معيارهاي با مفهوم مي باشد.

  

هدف از معيارهاي اندازه گيري فرآيند نرم افزار

•        اندازه گيري علاوه بر تخمين هزينه و زمان براي دريافت بازخورد (feedback) در طول توسعه سيستم نيز کاربرد دارد. به اين ترتيب وضعيت پيشرفت و ريسک نيز کنترل مي شود.

•        با اندازه گيري فرآيند ، اهداف بهبود آن نيز تعيين مي شود.

عوامل شکست و منشا آنها در پروژه هاي نرم افزاري

 

اندازه گيري نرم افزار

  اندازه گيري مبتني بر اندازه
Size-Oriented  

  

اندازه گيري مبتني بر تابع
Function-Oriented

 •        پارامترهايي که در محاسبه جدول عنوان شد عبارتند از :

–        تعداد ورودي هاي کاربر

–        تعداد خروجي هاي کاربر

–        تعداد جستجوهاي کاربر

–        تعداد فايل ها

–        تعداد واسط هاي خارجي

•        براي محاسبه Function-Point  از رابطه زير استفاده ميشود:

          FP = count total x [0.65+0.01 x Sum(Fi)]

Fi ها يا ضرايب تطابق پيچيدگي با پاسخ به سوالاتي محاسبه ميشود.

 

 

 

معيارهايي براي کيفيت نرم افزار

•        براي اندازه گيري کيفيت نرم افزار شاخصهاي ”صحت“، ”قابليت نگهداري“،  ”يکپارچگي“ و  قابليت استفاده ( usability) براي تيم نرم افزاري قابل استفاده است.

–        صحت : يک برنامه بايد در درجه اول درست کار کند.

–        قابليت نگهداري : قابليت نگهداري ، آساني تغيير در برنامه در هنگام بروز خطا يا تغييرات در محيط يا نيازهاي مشتري ميباشد.

–        يکپارچگي : قابليت استادگي نرم افزار در برابر حمله هاي سهوي يا عمدي ميباشد.

–        قابليت استفاده : user-friendly بودن و به کار آمدن براي کاربر

 

 

جمله قصار

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

Frank Llyod Wright

مدیریت پیکربندی .... Configuration Managment

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

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

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

جمله قصار

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

                                        Frank Llyod Wright

مدیریت زنجیره تامین(SCM(supply chain management

چكيده

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

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

 

مراحل شکل گيري مديريت زنجيره تأمين

مي توان گفت مفهوم مديريت زنجيره تأمين ترکيبي از مراحل پنج گانه مديريت است. مرحله اول را مي توان به عنوان حوزه تدارکات داخلي توصيف کرد. در مرحله دوم، نگرشي نسبت به تدارکات از تمرکز زدايي سازماني به تمرکز در کارکردهاي اصلي که از نگرشهاي جديد مرتبط با بهينه سازي هزينه و خدمت به مشتري گرفته شده بود، تغيير يافت. در مرحله سوم، عرصه تدارکات به طور چشمگيري گسترش پيدا کرد و ضمن انبار داري و حمل و نقل داخلي ، ارتباط عمليات داخلي با حوزه هاي عملکردي شرکاي تجاري را در بر گرفت. همان طور که مفهوم روابط کانالي رشد کرد، در مرحله چهارم مفهوم تدارکات نيز به مديريت زنجيره تأمين تغيير پيدا کرد. امروزه با کاربردهاي فناوري اطلاعات در مديريت زنجيره تأمين، مي توان گفت که مديريت زنجيره تامين در حال وارد شدن به مرحله پنجم يعني مديريت زنجيره تامين الکترونيک است. در ادامه هر يک از مراحل پنج گانه به طور مختصر توضيح داده مي شود.
1 - مرحله اول- تمرکز زدايي تدارکات: اين مرحله در يک دوره اي از اواخر قرن نوزدهم تا اوايل دهه 1960 شکل گرفت. در طول اين دوره، حوزه لجستيک به عنو ان يک منبع مهم مزيت رقابتي شناخته نشده بود. اساساً لجستيک به عنوان يک وظيفه واسطه با مديريت موجودي و تحويل شناخته مي شد و بنگاهها احساس مي کردند که لجستيک نمي تواند باعث سودآوري شود و بنابراين، سرمايه گذاري بالا درآن ارزشمند نيست.
2 - مرحله دوم – مديريت هزينه: در اواسط دهه 1960 مشخص گرديد که وجود ساختار و هدف در لجستيک و مديريت متمرکز برآن مي تواند مزيت رقابتي را براي يک شرکت به همراه داشته باشد. مرحله دوم در مديريت زنجيره تأمين در راستاي تأمل و بررسي روي دو نقطه بحراني و اصلي شکل گرفت. کانون اول را مي توان تلاش زياد شرکتها براي متمرکز کردن فعاليتهاي لجستيک در يک سيستم مديريتي مستقل توصيف کرد. از طريق ترکيب آنچه که قبلاً يک سري فعاليتهاي پراکنده بود در يک بخش مستقل ، هزينه هاي جداگانه مرتبط با حمل و نقل، موجودي و توزيع فيزيکي کاهش مي يابد و به طور همزمان بهره وري سيستم لجستيک به عنوان يک کل افزايش مي يابد. نقطه بحراني دوم را مي توان اميدواري براي تمرکز بنگاهها براي به کار گيري مفهوم هزينه کامل در لجستيک دانست. هدف اين استراتژي تلاشي جهت حداقل کردن هزينه کل لجستيک به واسطه تمرکز بر کاهش هزينه هاي يک يا دو کارکرد خاص لجستيک از قبيل حمل ونقل يا انبار داري است.

3 - مرحله سوم- يکپارچگي کارکردها: در طول دهه 1980، مديران اجرايي شرکتها پي بردند که تمرکز بر هزينه کل لجستيک يک شيوه مثبت براي مديريت کانال توزيع است. تا اين دوره ، اغلب مديران اجرايي به لجستيک به عنوان يک فعاليت تاکتيکي نگاه مي کردند و در برنامه ريزي استراتژيک شرکت تأثير خيلي کمي داشت. در اواسط دهه 1980، شرکتها پي بردند که به واسطه بهبود پيوسته فرايند ويکپارچگي بيشتربا شرکاء لجستيک مي تواند ارزشهاي استراتژيک زيادي را ايجاد کند.
4 - مرحله چهارم- مديريت زنجيره تأمين: در طول دهه 1990، شرکتها مفاهيم لجستيک يکپارچه و مديريت کانال تأمين را براي به کارگيري واقعيات جديد بازار توسعه دادند. زنجيره تأمين فراتر از لجستيک بوده و علاوه بر آن فعاليتهاي ديگري را نيز از جمله نحوه برخورد با شرکتهايي متعدد سازنده، هدف گذاري و تعيين استراتژي هاي خريد داخلي و خارجي، ارتقاي کيفيت شرکتهاي سازنده، بازاريابي و ارائه خدمات بهتر به مشتريان متعدد شامل مي‌شود.
5 - مرحله پنجم- مديريت زنجيره تأمين الکترونيک: به کمک فناوري اطلاعات حوزه عملکردمديريت زنجيره تأمين گسترش يافته است. هدف از ايجاد مديريت زنجيره تأمين الکترونيک کاهش هزينه هاي نقل وانتقال اطلاعات و نهايتاً محصولات از يک طرف و گسترش فرصتهاي تجاري و دامنه همکاري بين شرکتها از طرف ديگر بوده است.

 

تعريف مديريت زنجيره تأمين
از چندين زاويه مي توان به مديريت زنجيره تامين نگاه کرد. به مثابه اغلب فلسفه هاي مديريت، تعاريف مديريت زنجيره تأمين نيز بايد هم اهداف استراتژيک و هم اهداف تاکتيکي را پوشش بدهد. هند فيلد و نيکولس(Handfield & Nichols) مديريت زنجيره تأمين را از طريق تفکيک مفاهيم در دو اصطلاح ، زنجيره تأمين و مديريت زنجيره تامين تعريف مي کنند.
زنجيره تأمين شامل همه فعاليتهاي مرتبط با جريان و انتقال کالاها از مرحله مواد خام به مصرف کننده نهايي و جريانهاي اطلاعاتي مرتبط با ان است. مديريت زنجيره تأمين يعني يکپارچه سازي اين فعاليتها از طريق بهبود روابط زنجيره تأمين براي رسيدن به يک مزيت رقابتي پايدار.
آيرس(Ayers) نيز تعاريف زير را براي زنجيره تأمين و مديريت زنجيره تأمين ارائه مي کند.زنجيره تأمين يعني، شکل دادن به فرايندهاي جريانات فيزيکي ، اطلاعاتي ، مالي و دانش به منظور ارضاي احتياجات مصرف کننده نهايي از طريق محصولات و خدمات مرتبط با تأمين کنندگان. مديريت زنجيره تأمين عبارت است از: طراحي، نگهداري و عمليات فرايندهاي زنجيره تأمين براي برآورده کردن احتياجات مصرف کنند نهايي.
به عبارت ديگر، زنجيره تأمين، شبکه اي از سازمانهاست که با ارتباطي بالا دستي ( تأمين کنندگان) به پايين دستي (توزيع کنندگان)، در فرايندها و فعاليتها درگيرند و به صورت محصولات و خدمات ارائه شده به مشتري نهايي، توليد ارزش مي کنند. مديريت زنجيره تأمين يعني يکپارچه سازي سازمانهاي درگير و هماهنگ سازي بهتر جريانهاي مواد، اطلاعات و مالي. در شکل شماره يک فرايند مديريت زنجيره تأمين به صورت ساده نشان داده شده که در آن جريان اطلاعات و مواد مشخص شده است. (شكل 1)

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

مديريت زنجيره تأمين موجب هماهنگ سازي جريانهاي مواد و اطلاعات به وسيله آخرين محصولات نرم افزاري از قبيل سيستم هاي برنامه ريزي پيشرفته(Advanced Planning Systems)، مي شود. در چند سال اخير، پيشرفت در فناوريهاي اطلاعاتي و ابزارهاي ارتباطي و همين طور روشهاي حل مدل هاي کمي بزرگ، چشم اندازهاي جديدي را براي برنامه ريزي و کنترل توليد جريانات توليد در طول يک زنجيره تأمين به وجود آورده است. يک سفارش مشتري ، پيش بيني هاي تقاضا يا گرايشهاي بازار را مي توان در فعاليتهاي مورد نياز وارد کرد و فوراً به همه قسمتها در زنجيره تأمين ارسال کرد. اين باعث مي شود تا زمان بنديهاي دقيقي ايجاد شوند که از تکميل سفارشات در سر وقت پشتيباني مي کنند.

روند جهاني مديريت زنجيره تأمين
در دهه اخير و به دنبال مديريت زنجيره تأمين الکترونيک، روند مديريت زنجيره تأمين نيز با تغييرات شديدي روبه رو گرديد، چرا که از حالت سازماني يا منطقه اي به حالت جهاني بايد تغيير کند. بدين ترتيب توليد از روش توليد استاندارد و انبوه به سمت توليد منعطف محلي سوق داده شد. لازمه اين امر نيز تغيير ساختاري آن از حالت متمرکز به حالت نيمه متمرکز و ايجاد واحدهاي استراتژيک مستقل(Strategic Bussines Units) بوده است. تغيير ديگري که در اين روند مي‌توان مشاهده کرد افزايش سهم برون سپاري (Outsourcing) است. شرکتهاي مديريت زنجيره تأمين براي افزايش مزيت رقابتي خود در طول فرايند تأمين تمرکز خود را روي مراحلي اختصاص مي دهند که ارزش افزوده بيشتري را براي مشتري و شرکت فراهم سازد. بدين ترتيب بخشهايي با ارزش افزوده کمتر را به شرکتهاي ديگر داده و ترجيح مي‌دهند خريد خارجي كنند. بدين ترتيب نقش استراتژي هاي همکاري بسيار تعيين کننده شده است. بعضي از نتايج اين استراتژي ها به شرح زير است:

_ کاهش هزينه هاي مستقيم و غير مستقيم؛
_ کاهش هزينه هاي سرمايه گذاري؛
_ کاهش ميزان پرداخت ماليات؛
_ کاهش هزينه لجستيک؛
_ ارائه خدمات بهتر به مشتريان؛
_ افزايش مزيتهاي رقابتي با استفاده از مزيتهاي رقابتي همکاران؛
_ بهره گيري از تجربه و دانش افراد و سازمانهاي محلي.

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

-----------------------------------------------------------------------------------------------------

کاربرد شبيه‌سازي در مديريت زنجيره تأمين

هدف از مديريت زنجيره تأمين، مديريت کل زنجيره تأمين از تأمين‌کنندگان تا توليد‌کنندگان، خرده‌فروشان و مشتريان نهايي است. SCM سه هدف مهم را دنبال مي‌کند:

· کاهش حجم موجودي‌ها

· افزايش سرعت معاملات از طريق تبادل داده‌ها در زمان مناسب

· افزايش ميزان فروش از طريق در نظر گرفتن نيازهاي مشتريان

مديريت زنجيره تأمين روشي است براي بهبود دسترسي به مواد اوليه، ساخت محصولات و يا خدمات و انتقال آن به مشتريان. SCM داراي پنج بخش اصلي است: [1]

· برنامه‌ريزي: مديريت منابع مورد نياز براي برآوردن نيازهاي مشتريان با کيفيت مورد نظر و به شکل بهينه. اين قسمت، بخش استراتژيک SCM به شمار می‌آيد.

· منابع: انتخاب تأمين‌کنندگان مناسب، توجه به روندهاي قيمت‌گذاري، تحويل و پرداخت به آنها. رويه‌هاي مديريت انبار شامل دريافت، بازبيني و انتقال به خط توليد نيز بايد تعيين شوند.

· توليد: فعاليت‌هاي لازم براي کنترل کيفي، بسته‌بندي و آماده‌سازي جهت ارسال کالاها و خدمات

· ارسال: هماهنگ‌سازي دريافت سفارش از مشتريان و آماده سازي شبکه‌اي از انبارها و انتخاب روش‌هاي حمل‌و‌نقل

· ارجاع: بخشي براي مرجوع ساختن کالاهاي معيوب از طرف مشتريان.

يک ابزار مهم براي تحليل و بررسي زنجيره تأمين مي‌تواند شبيه‌سازي باشد. شبيه‌سازي با داشتن امکانات نمايش گرافيکي قادر است مديران را در تصميم‌گيري براي بهبود عملکرد زنجيره تأمين ياري دهد. در ادامه به سه مورد از کاربردهاي نرم‌افزارهاي شبيه‌سازي Enterprise Dynamics در مديريت زنجيره تأمين در يک کارخانه اشاره مي‌شود:

1. سيستم مرتب سازي، انجام تجارت الکترونيک: DOCData

DOCData انجام عمليات تجارت الکترونيک را براي شرکت‌هاي تجارت الکترونيک که محصولاتي از قبيل CDهاي ويدئويي مي‌فروشند، بر عهده دارد. DOCData محصولات را به بيش از 20000 مشتري در روز حمل مي‌نمايد. اين شرکت براي هر سفارش، يک صورت‌حساب تهيه نموده و محصولات جداگانه را جمع‌آوري مي‌نمايد. تمامي سفارشات بر روي تسمه نقاله قرار گرفته، تفکيک و مرتب مي‌شوند. هنگامي‌که يک سفارش تکميل گرديد، اقلام به همراه صورت‌حساب در داخل يک بسته قرار گرفته و مستقيماً به مشتري نهايي ارسال مي‌شوند.

يکي از اهداف اصلي DOCData افزايش کارآيي کل سيستم و کاهش پيوسته هزينه‌هاي هر سفارش است. هم‌چنين افزايش مستمر گردش کالا و پيش‌بيني دشوار سايز سفارش نيز از مواردي هستند که بايد مورد توجه قرار گيرند. به منظور کسب نگرش دقيق‌تر نسبت به اين سيستم پيچيده، DOCData به يک ابزار شبيه‌سازي نياز داشت تا بتواند ديد بهتري نسبت به اين سيستم بسيار پويا به دست آورد.

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

2. انبارداري: مرکز توزيع اروپا: XEROX – Frans Maas

Frans Maas شرکت ارائه‌دهنده خدمات لجستيکي در اروپا مي‌باشد. در ميان ساير عمليات تجاري، آنها مرکز توزيع Xerox در اروپا مي‌باشند. در طي ساليان گذشته محصولات Xerox کاملاً متحول شده‌اند. در گذشته Xerox تنها سازنده و توزيع‌کننده دستگاه‌هاي بزرگ کپي بود، ولي هم اکنون علاوه بر آن سازنده چاپگرهاي و کپي‌هاي کوچک نيز مي‌باشد. حجم فروش اين دستگاه‌هاي کوچک بسيار افزايش يافته است. اين مسئله بدين معني است که مفاهيم لجستيکي به طور عمده‌اي دستخوش تحول گرديده است.

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

شرکت Incontrol Enterprise Dynamics يک ابزار واسط را طراحي نمود که قادر بود سناريوي جديدي را در عرض يک ساعت توسط نرم‌افزار شبيه‌سازيED بسازد. با استفاده از ارتباط با يک بانک اطلاعاتي Access که حاوي تمامي اطلاعات محصولات بود و برقراري ارتباط جهت تعريف لي‌اوت در Excel، سناريوي جديد به راحتي ايجاد ‌گرديد. از بين اين سناريوها بهترين راهکار بر اساس کل زمان مورد نياز براي يک سفارش خاص انتخاب مي‌گرديد.

جهت دستيابي به بهترين راهکار در خصوص لي‌اوت، يک مدل انيميشن (با استفاده از ED) ايجاد گرديد. نمايش 3 بعدي از لي‌اوت جديد Frans Maas را قادر نمود که طرح انبار را به هر کسي از کارگر انبار تا اعضاي هيأت مديره بتواند بقبولاند. از آنجا که اين مدل شامل محصولات به طور تک‌تک اقلام بوده و هم‌چنين مدل از سفارشات “Real Life” استفاده مي‌نمايد، مدل به عنوان ابزار عملياتي به خوبي به کار گرفته ‌شد.

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

 

جمله قصار

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

دلایل شکست مهندسی مجدد نرم افزار

	نکات مهم در انجام يک پروژه مهندسي...۱.   دلایل شکست مهندسی مجدد نرم افزار
در سال 1999 میلادی یک گروه تحقیقاتی در وزارت دفاع آمریکا، مطالعاتی در مورد دلایل شکست مهندسی مجدد در چندین سازمان انجام دادند. دلایل آنان در قالب 10 دسته زیر گروهبندی شده است: ·    سازمان سهواً استراتژی مهندسی مجدد ناقص و یا معیوب را می پذیرد: این استراتژی ها به علت فرضیات ضعیف یا عدم توجه به جزییات ممکن است همه گامها و جزییات در نظر نگیرند. اگر یک سازمان دانش موجود را در مورد یک سیستم نادیده بگیرد یا رها کند ممکن است نقش سیستم کمرنگ شده و یا متروگ گردد. ·    سازمان به طور نا مناسب از پیمانکاران و مشاوران خارجی استفاده می کند: افراد خارج از سازمان دامنه فهم ، مهارتهای تکنیکی و منابع انسانی را به سازمان می آورند. اما آنها به اندازه خودی ها (افراد عضو سازمان) از نرم افزار موجود نمی دانند. برای اینکه آنها بتوانند برای سازمان به خوبی کار کنند می بایست نقش شان به طور واضح مشخص و کنترل شود. افراد خارج سازمان ممکن است با منافع نیروهای داخلی مخالف باشند و یا هزینه ها را حداکثر کنند. افراد خارج سازمان ممکن است کنترل را بیشتر از داخلی ها به دست بگیرند واین به دلیل فقدان بینش داخلی هاست. ·     نیروی کار روی تکنولوژی قدیمی با برنامه های آموزشی نا مناسب و نا کافی پیوند خورده است: زمانیکه سخت افزار تغییر کند ممکن نیست سیستم ادامه پیدا کند. علاوه بر آن، زمانیکه سبک برنامه نویسی جدید اختیار شود فقدان آموزش مناسب ممکن است باعث شکست مهندسی مجدد در پروژه شود. در این شرایط می بایستی یک تلاش مستمر و جدی به کار برد تا مهارتهای نیروی کار موجود بهبود یابد یا نیروهای جدیدی جایگزین نیروی قبلی شود.  ترکیبی از نیروهای جدید و قدیم نیز راه حل دیگری برای تطابق با تکنولوژی جدید و جلوگیری از شکست مهندسی مجدد در سیستم سازمان است. ·      سازمان سیستم موروثی[1] را تحت کنترل ندارد: قبل از اینکه سیستم به طور موثر مدیریت شود یک خط مبنای مدیریت پیکربندی سیستم برای کمک به سیر تکاملی منظم سیستم باید ایجاد شود. سیستم موروثی نیاز دارد که که به خوبی با درک اولویت درخواست تغییرات و تاثیرآنها روی سیستم مستند شود. ·      استخراج نیازها و معتبر سازی فرایندها خیلی کم است: تشخیص نیازها یک مسئله خیلی مهم است. نقص ها و یا کمبود هایی در استخراج نیازمندیها و معتبر سازی فرآیندها ممکن است وجود داشته باشد. این نیازها شامل نیازهای عملیاتی، غیر عملیاتی ، نیازهای کاربران و مشتریان می باشد. در پی این نیازها، نیازهای نرم افزاری، سخت افزاری، معماری، نگهداری و منطقی مطرح می شود. همه اینها منعکس کننده این مطلبند که نیازها تک بعدی نیستند. ·    معماری نرم افزار یک ملاحظه اولیه مهندسی مجدد نیست: شکست ممکن است وقتی یک ارزیابی منظمی از معماری نرم افزار سیستم موروثی و هدف سیستم به عنوان یک عامل محرک در توسعه رویکرد تکنیکی مهندسی مجدد وجود ندارد اتفاق بیافتد. ارزیاب معماری سیستم موروثی ممکن است تصمیم بگیرد چه استراتژیی را قبول کند. ·    هیچ تصور واضح و جدایی از فرایند مهندسی مجدد وجود ندارد: ابزاری که در تکامل یک سیستم موروثی دخالت دارند تاثیر زیادی در موفقیت ویا شکست مهندسی مجدد در یک سیستم دارد. وجود یک فرآیند چرخه مستند سازی و تولیدات کاری متناظر، به عنوان مدرکی برای فرآیند مهندسی مجدد، اغلب اوقات اشتباهاً دیده می شود.  در اینجا تعریف مجموعه ای از وظایف و راهنمایی ها برای انجام هر گام ضرورت دارد. چهار عامل اصلی بحران در مهندسی مجدد شامل انسانها، تکنولوژی، فرآیند و منابع در دسترس است که عدم وجود با کیفیت هر یک از عوامل  باعث عدم تولید یک محصول با کیفیت خواهد شد. ·     برنامه ها با برنامه ریزی و تجزیه و تحلیل نا مناسب و نا کافی پی گیری می شود: پروژه ها اغلب روی مشکلات نرم افزاری سطح پایین تمرکز می کنند و مدیریت ماهرانه برنامه و جنبه های دیگر طراحی مهندسی مجدد دچار غفلت می شود. ·     مدیریت فاقد تعهد طولانی مدت است: مدیریت پشتیبانی به معنای نظارت دقیق و پی گیریها مسیرها بدنبال یکدیگر طبق برنامه است. اگر توجه مدیریت در مسیر یک پروژه مهندسی و یا مهندسی مجدد با پروژه های دیگر منحرف شود او متوجه نخواهد شد چه زمانی و چه چیزی اشتباه شده است. مدیریت تصمیمات تکنیکی را از پیش تعیین می کند: در شرایطی دستور یا حکم برای مهندسی مجدد توسط مدیریت رده بالا تر صادر می شود.  در این شرایط مدیریت رده بالاتر رویکرد تکنیکی، زمان بندی، هزینه و کارایی را بدون در نظر گرفتن نیروی مناسب تیم پروژه و یا توافق آنها از پیش تعیین می کند. [1] Legacy System

برآورد نيروي كار موردنياز و هزينه نرم افزار

 

اشاره : يكي از مهم‌ترين مسائلي كه مديران پروژه‌هاي نرم‌افزاري به آن توجه دارند استفاده از ابزارها ، تكنيك‌ها و روش‌هاي مختلف براي برآورد و كنترل‌‌ ‌راندمان كاري است. اين عامل مي‌تواند براي برآورد نيروي انساني، مدت زمان مورد نياز پروژه‌ها و برنامه‌ريزي بسيار سودمند باشد. دانستن اندازه نرم‌افزار قبل از توليد آن مي‌تواند‌ ما را در اين برآوردها ياري رساند. روش‌هاي مختلفي براي به دست آوردن اندازه نرم‌افزار وجود دارد از جمله: شمارش خطوط برنامه LOC) ،‌COCOMO) و ‌MKII. ولي تمام اين روش‌ها داراي نقاط ضعف فراواني هستند كه از آن ميان مي‌توان به عدم سازگاري با انواع مختلف نرم‌افزار و سختي محاسبه، اشاره كرد. (كه همگي آن‌ها به تفصيل در مقاله <اندازه‌گيري نرم افزار، چرا و چگونه> در شماره 60‌ ماهنامه شبكه موردبررسي قرارگرفته‌اند.) از اين رو بسياري از متخصصان و استادان نرم‌افزار تلا‌ش‌كرده‌اند روش آسان و استانداردي را براي اندازه گيري نرم‌‌افزارهاي امروزي پيدا كنند. ‌‌COSMIC-FFP روش استانداردي است براي اندازه‌گيري انواع مختلف نرم‌افزار با دقت عمل بالا و توانايي محاسبه از مراحل اوليه توليد تا نصب. اين مقاله سعي دارد با طرح مثال‌هاي ساده، اين استاندارد را بررسي كند.‌
برآورد نيروي كار موردنياز و هزينه نرم افزار يكي از اولين سوالاتي كه در شروع هر پروژه نرم‌افزاري مطرح مي‌شود، هزينه توليد نرم‌افزار و اندازه آن است. براي محاسبه هزينه نرم‌افزار بايد اندازه نرم‌افزار را پيدا كنيم. روش‌هاي مختلفي براي اندازه‌گيري اندازه نرم‌افزار وجود دارد؛ مثل اندازه خطوط برنامه. ولي ازآن جايي كه برنامه‌نويسان مختلف روش‌هاي متفاوتي در نوشتن كد دارند و دو برنامه با اندازه مختلف مي‌تواند كارايي مشابهي داشته باشند، اين روش استاندارد نيست. روش ديگري كه مي‌توان از آن استفاده كرد، مشخص‌كردن كارايي و عمليات نرم‌افزار است. بدين ترتيب كه هر نرم‌افزار را با توجه به كارايي و پيچيدگي فني آن اندازه‌گيري كنيم. يكي از روش‌هاي معمول براي به دست آوردن اين مقدار، استفاده از فرمول ‌‌Albrecht است كه با توجه به تعداد عمليات، كارايي و پيچيدگي فني سيستم مقدار ‌Function Point) FP) را مشخص مي كند. مثلا اگر براي يك نرم‌افزاري مقدار 68 به دست آيد و فرض كنيم نوشتن هر ‌FP براي هر برنامه نويس به طور متوسط دو روز وقت مي‌گيرد، تهيه اين نرم افزار 136 روز طول خواهد كشيد. در بسياري از كشورهاي جهان ازجمله كشور انگلستان، بيشتر قراردادهاي نرم‌افزاري بر اساس‌‌ ‌FP بسته مي‌شود و هزينه نرم‌افزار را با توجه به مقدار ‌FP برآورد مي كنند. در اين‌جا سعي شده است روش بهتري براي اندازه گيري نرم‌افزار بررسي شود. اين روش‌ كه ‌COSMIC-FFP نام دارد، استاندارد جديد كشورهاي اروپايي و امريكايي است. نگاهي به استاندارد ‌‌COSMIC-FFP گروه Common Software International Consortium) ‌‌COSMIC) در سال 1998 با هدف توسعه روش‌هاي اندازه‌گيري نرم‌افزار تشكيل شد. هدف عمده اين گروه، ارائه روشي آسان براي تخمين اندازه و هزينه نرم‌افزار با‌توجه به نيازها و درخواست‌هاي كاربران است. استاندارد ارائه‌شده اين گروه براي اندازه‌گيري نرم‌افزار، ‌‌COSMIC-FFP است كه مي‌توان با آن بسياري از نرم‌افزارهاي مالي (حسابداري، بانكداري و...)، نرم‌افزارهاي‌ بلادرنگ (مثل نرم‌افزارهاي مخابراتي) و نرم‌افزارهاي چند‌منظوره را اندازه‌گيري نمود. با استفاده از اين استاندارد امكان اندازه‌گيري نرم‌افزارهاي گوناگون وجود ‌دارد. ولي نمي‌توان‌ نرم‌افزارهاي بسيار پيچيده فني را اندازه‌گيري كرد. يكي از نقاط قوت اين استاندارد اين است كه با استفاده از آن مي‌توان اندازه تمامي اجزاي نرم‌افزار را همان‌طور كه كاربر مي‌بيند، محاسبه كرد. شكل 1- نمايش لايه‌اي معماري‌ نرم‌افزار ‌روش ‌‌COSMIC-FFP از دو مرحله تشكيل شده‌است كه شامل تعدادي رويه و اصول مي‌باشد و مي‌توان با آن اندازه نرم‌افزار را محاسبه نمود. در مرحله اول نيازهاي كاربران ‌‌(System Specification) به مدل نرم افزاري ‌COSMIC-FFP تبديل مي‌شود و در مرحله دوم، اجزاي اين مدل، اندازه‌گيري مي‌شوند. قبل از محاسبه اندازه اين اجزا، نرم‌افزار بايد به فرم كلي ‌‌‌COSMIC در بيايد. فرم كلي ‌‌COSMIC لايه‌هاي نرم‌افزاري را مشخص مي‌نمايد وبهمحاسبه‌كننده كمك مي‌كند با استفاده از اين لايه‌ها، نيازهاي استفاده‌كننده را طبقه‌بندي نمايد. همان‌طور كه در شكل 1 مشاهده مي‌كنيد در اين مثال، نيازهاي مختلف به لايه هاي مختلف تعلق دارند. ‌پس از اين مرحله، مي‌توان اين نيازها را به چند رويه‌كاري و چند مدل انتقال اطلاعات (‌خواندن‌، نوشتن‌، ورودي و خروجي‌) تقسيم‌نمود. بعد از اين كار، قانون‌هاي اندازه‌گيري برروي اين مدل‌ها اعمال مي‌شود و مقدار عددي اندازه نرم‌افزار مشخص مي‌شود. اين مقدار عددي برحسب ‌‌Cfsu محاسبه مي گردد.‌ ناگفته نماند كه ‌واحد اندازه‌گيري در اين استاندارد، ‌يك Cosmic functional size unit) Cfsu) است.‌‌‌‌ ‌مدل اصلي اندازه گيري در ‌COSMIC شكل 2 مدل اصلي و روند محاسبه اندازه گيري نرم افزار با استفاده از اين استاندارد را نشان مي‌دهد. چنان كه ديده مي‌شود، در اين مدل اصلي محاسبه اندازه نرم‌افزار در استاندارد ‌COSMIC‌ نشان داده‌شده است. در ادامه تمامي اجزاي اين مدل از آغاز تا انجام با شرح مثال هاي ساده توضيح داده خواهد شد. ‌   شكل‌2- مدل اصلي اندازه گيري‌ استخراج نيازهاي كاربران يكي از مهم‌ترين عوامل مورد توجه در اندازه‌گيري نرم‌‌افزار با ‌‌COSMIC امكاناتي است كه سيستم در اختيار استفاده‌كنندگان قرار مي‌دهد و در واقع رويه‌اي است كه نرم‌افزار بايد در پيش بگيرد تا درخواست‌ها و نيازهاي كاربران را تامين كند. براي استخراج اين نيازها اكثر اوقات مي‌توان به مستندات اوليه سيستم مراجعه نمود. البته در مواقعي هم كه مستندات برنامه وجود ندارد و نرم‌افزار نصب شده است، باز مي‌توان اين نيازها را از نرم‌افزار نصب شده استخراج نمود. شكل 3 منابع استخراج نيازهاي كاربران از راه هاي ذكر شده را نشان مي‌دهد. براي مثال اگر سيستم مكانيزه كتابخانه را در‌نظر بگيريد، برخي از نيازهاي كاربردي استفاده‌كنندگان را مي‌توان به شرح زير نام برد: ‌‌- كنترل كردن كارت عضويت ‌ - كنترل كردن پرونده امانات براي پيدا كردن كتاب‌هايي كه اعضا به امانت گرفته‌اند و بازنگردانده‌اند.‌ شكل 3- منابع استخراج نيازهاي كاربران در COSMIC ‌ - امانت كتاب - برگشت كتاب توسط اعضا همانطور كه مشاهده مي‌كنيد، استخراج نيازهاي كاربران ‌‌‌‌(FUR) و عمليات سيستم كار مشكلي نيست. ولي قبل از هرگونه محاسبه نرم‌افزار (همان‌طور كه در شكل 2 نيز مشخص شده است)، دانستن اهداف اندازه‌گيري و محدوده آن اهميت دارد. هدف اندازه‌گيري، دليل اندازه‌گيري و نوع استفاده از نتايج محاسبه را مشخص مي‌كند. به عنوان نمونه در مثال سيستم كتابخانه، هدف از اندازه‌گيري را مي توان به شرح زير تعيين كرد: ‌دليل اندازه گيري ‌‌ براي اندازه‌گيري‌ نيازهاي كاربردي استفاده‌كنندگان (‌براي ورودي فرمول‌) و استفاده در رويه اندازه‌گيري (‌تخمين‌) ميزان كوشش كاري برنامه‌نويسان سيستم.‌ محدوده اندازه گيري‌ محدوده اندازه‌گيري در واقع محدوديت‌ها و ملزومات يك اندازه‌گيري را مشخص مي كند. براي مثال در سيستم كتابخانه اين حدود به شرح زير است: ‌ ‌- فقط نيازهاي كاربران در دسترس است.‌ - زبان برنامه نويسي‌: جاوا‌ - پايگاه اطلاعاتي: اوراكل ‌ - برنامه نويسي شي گرا‌ -لايه‌هاي نرم‌افزاري: نرم‌افزار و پايگاه اطلاعاتي ‌عامل اوليه ديگري كه قبل از محاسبه اندازه نرم‌افزار الزامي به‌نظر مي‌رسد، ديد محاسبه‌كننده است. در اين‌باره مي‌توان دو ديدگاه را مورد‌بررسي‌قرار داد: نظر استفاده كننده سيستم و نظر برنامه‌نويسان و تهيه كنندگان نرم‌افزار. اين مسئله به عنوان نمونه در همان مثال در سيستم كتابخانه به شرح زير است: نظر استفاده كنندگان ‌ - استفاده‌كنندگان سيستم: دانشجويان و متصدي كتابخانه مي باشند.‌ - اين استفاده‌كنندگان فقط از بخشي از توانايي‌هاي سيستم اطلا‌ع دارند كه با آن كار مي كنند. ‌ - اگر اندازه‌گيري نرم‌افزار از نظر اين نوع استفاده كنندگان محاسبه شود، بايد فقط اندازه اجزاي سيستم كه كاربر با آن در تماس مستقيم است، محاسبه گردد.‌ نظر برنامه‌نويسان/ توليد كنندگان نرم‌افزار دراين ديدگاه بايد اندازه تمامي اجزاي سيستم محاسبه شود. براي محاسبه و تخمين نيروي مورد‌نياز و هزينه نرم‌افزار بايد ديد برنامه‌نويس مد‌نظر قرار مي گيرد و تمامي اجزاي سيستم در محاسبه در نظر گرفته شوند. شكل 4-مرحله‌ Mapping ‌مرحله ‌‌Mapping ‌ ‌همانطور كه در شكل 2 (‌مدل اصلي اندازه گيري) ديده مي‌شود، مرحله اول اين مدل، مرحله مقدماتي يا تبديل نيازهاي كاربران‌‌ ‌‌(FUR) به مدل عمومي ‌COSMIC است. اين مرحله اصطلاحا مرحله‌‌ ‌Mapping نام دارد كه همان‌طور كه در شكل 4 مشاهده مي كنيد، ‌FURs را به مدل نرم‌افزاري عمومي ‌COSMIC تبديل مي كند. در اين مرحله با استفاده از روش ها و رويه هاي گوناگون، ورودي ‌‌‌‌(FUR) به مدل عمومي COSMIC كه مدل‌ مناسب‌تري براي محاسبه اندازه نرم‌افزار است، تبديل مي‌شود. در اندازه‌گيري نرم‌افزار سوالاتي مانند <چه قسمت‌هايي از سيستم جزء نرم‌افزار و چه قسمت‌هايي جزء سيستم عامل ‌‌‌(OS) محسوب مي‌شود؟> ممكن است در ذهن پيش بيايد. به همين جهت ‌‌‌COSMIC پيشنهاد مي‌كند كه از مدل‌ CONTEXT ‌استفاده شود. يعني هر قسمت از سيستم ترسيم گردد و جريان اطلاعات در آن بررسي شود. ساده‌ترين مدل جريان اطلاعات در نرم‌افزار در شكل 5 نمايش داده شده است.‌ شكل 5-مدل‌ اصلي‌جريان‌اطلاعات‌در نرم‌افزار همانطور كه در شكل 5 مشاهده مي كنيد، نرم افزار به وسيله سخت افزار (صفحه كليد، نوار خوان و...) از يك سو و پايگاه اطلاعاتي (هاردديسك‌) از طرف ديگر احاطه شده است و دو انتها دارد: ‌انتهاي جلويي ‌(Front-end) و انتهاي عقبي (Back-end). در قسمت انتهاي جلويي دو گروه انتقال اطلاعات وجود دارد: ورودي‌‌ ‌‌(entry) و خروجي‌‌ (exit). ورودي همان اطلاعات وارد شده از طرف كاربر و خروجي نيز انتقال اطلاعات از سوي سيستم به كاربر است. در قسمت انتهاي عقبي نيز دو گروه انتقال اطلاعات وجود دارد: نوشتن اطلاعات در پايگاه اطلاعاتي (‌توسط نرم‌افزار) و خواندن اطلاعات. ‌هدف ‌‌COSMIC اندازه‌گيري نرم‌افزار بر اساس ‌FURهاي موجود است. وقتي ‌FURها مشخص شدند، مي‌توانيم آن‌ها را به نرم‌افزار/سخت‌افزار موجود در سيستم ربط دهيم. ولي همان‌طور كه قبلا توضيح داده شد،‌‌ COSMIC ‌فقط به ‌FURهايي توجه دارد كه به نرم افزار مربوط مي‌شوند. همان‌طور كه در شكل 6 مشاهده مي كنيد در نرم‌افزارهاي بازرگاني امروزي نيازهاي كاربران ‌FURها به لايه‌‌ ‌Application (نرم‌افزار) مرتبط مي شوند. زيرا اين لايه مستقيما با كاربر در ارتباط است. شكل 6- مدل جريان اطلاعات در نرم افزار چند لايه‌اي مرزهاي نرم افزار و رويه هاي كاربردي تعيين‌كردن مرزهاي نرم‌افزار با نوع، هدف و ديدگاه اندازه‌گيري (‌استفاده كننده/‌برنامه‌نويس) ارتباط مستقيم دارد. مرزهاي نرم‌افزاري در واقع اينترفيس‌هايي هستند در ميان نرم‌افزار و استفاده‌كننده؛ منظور از استفاده‌كننده مي‌تواند لايه ديگري از نرم‌افزار يا همان كاربر باشد. براي مشخص‌كردن مرز نرم‌افزاري و رفع ابهام، ‌‌COSMIC پيشنهاد مي‌كند دو عامل را در نظر بگيريم: كسي يا قسمتي از نرم‌افزار كه بخشي را فعال مي‌كند (باعث رويدادي مي‌شود) و قسمتي كه تحت تاثير قرار مي گيرد (‌رويه عملياتي). مرز نرم‌افزار بين اين دو قرار دارد. البته ديدگاه اندازه‌گيري در اينجا مهم است و تفاوت در ديدگاه اندازه‌گيري اين مرز را تغييرمي‌دهد. مثلا وقتي از ديدگاه استفاده‌كننده سيستم نگاه مي‌كنيم، دو مرز وجود دارد: بين نرم‌افزار و كاربر و بين نرم‌افزار و پايگاه اطلاعاتي ( شكل 5). براي وضوح بيشتر يك وب‌سايت را از ديد كاربر تجسم كنيد. كاربر برروي يك لينك كليك مي‌نمايد و محتويات صفحه را مشاهده مي كند. ولي اگر اين وب سايت را از ديد يك طراح وب در نظر بگيريد، هر لينك عامل سه حركت اطلاعات مي‌گردد. همان‌طور كه قبلا اشاره شد، اطلاعات در هر لايه در حركت هستند (‌خواندن‌، نوشتن‌، ورودي و خروجي) ولي لزوما اين امر بدين معنا نيست كه خروج اطلاعات دائما به سمت كاربر باشد. مثلا اگر بخواهيم اطلاعاتي را برروي پايگاه‌اطلاعاتي ذخيره كنيم (‌نوشتن يا‌ Write)، در واقع اين عمل نوشتن به‌وسيله لايه نرم‌افزار يك ورودي ‌‌‌(Entry) اطلاعات به لايه پايگاه اطلاعاتي است. ولي در مورد خواندن اطلاعات ‌(Read) ‌از پايگاه اطلاعاتي، مسئله پيچيده‌تر از خواندن اطلاعات مي‌شود. همانطور كه در شكل 7 مي‌بينيد وقتي يك جستجو از طرف لايه ‌‌Application درخواست مي‌شود، اين درخواست در واقع يك ورودي است از طرف لايه و خواندن‌‌‌اطلاعات، در واقع توسط لايه ‌‌ ‌Device Driver هدايت و كنترل مي‌گردد. شكل 7- جستجو توسط‌ لايه ‌ ‌ همانطور كه در شكل 7 مشاهده مي‌كنيد، يك ورودي ‌‌‌‌(E: Entry) باعث به وجود آمدن دو حركت مي‌شود: خواندن ‌‌‌(R: Read)‌ از پايگاه اطلاعاتي از لايه ‌Device Driver و خروج ‌‌‌(X: Exit) به لايه‌‌ Application. پس از شناسايي مرزهاي نرم‌افزار (همان‌طور كه در شكل 2 مشخص شده) مرحله شناسايي رويه‌هاي كاربردي قراردارد. شناسايي يك رويه كاربردي يا ‌‌Functional process كار سختي نيست. در واقع يك رويه كاربردي قسمتي از نيازهاي كاربران است كه توسط آنان از سيستم در‌خواست مي‌شود و باعث حركت اطلاعات مي‌شود و تا وقتي تمام نيازهاي كاربر را فراهم نكند، اين رويه ادامه دارد. يك رويه كاربردي حداقل شامل دو حركت اطلاعات مي باشد (‌يك ورودي: ‌ ‌E و يك خروجي:‌‌ X) نوشتن اطلاعات (W)، فقط متعلق به يك لايه مي باشد و داراي تعدادي رويداد‌‌ ‌Events است. مثلا در سيستم كتابخانه اگر فرض كنيم كه هدف يك رويه كاربردي، ايجاد يك عضو جديد است، مي توان رويدادهاي زير را در نظر گرفت: شكل 8- مدل كنترل‌كردن كارت عضويت كتابخانه يك ورودي: ‌‌ 1 X Entry(اطلاعات عضو جديد)‌ يك نوشتن: ‌‌ 1X Write(نوشتن اطلاعات عضو در پايگاه اطلاعاتي) ‌ يك خروجي: ‌‌ ‌1X Exit(پيغام خطا يا تاييد ثبت اطلاعات عضو) ‌‌ ‌‌ ‌يكي ديگر از نيازهاي كاربران در سيستم كتابخانه، كنترل‌كردن كارت عضويت است. اگر بخواهيم اين رويه را به صورت مدل نشان دهيم، شكل 8 را مي توانيم ترسيم كنيم. ‌ مراحل زير را مي توانيد در شكل 8 به وضوح مشاهده كنيد: ‌‌ 1X Entry- (از كاربر به لايه‌Application ) 1X Exit - ‌از لايه (‌Application ‌به سيستم مديريت پايگاه اطلاعاتي رابطه اي يا‌ ‌RDBMS) ‌‌ 1X Entry- (به‌‌ ‌RDBMS) - 1X Read (از پايگاه اطلاعاتي) ‌ ‌-‌‌ 1X Exit (از ‌‌RDBMS به لايه‌ Application) - 1X Entry (به لايه‌ Application) -‌‌ 1X Exit (پيغام به كاربر) ‌ شكل 9- مدل‌‌ ‌ERD سيستم كتابخانه شناسايي جهت انتقال اطلاعات اولين قدم براي شناسايي جهت انتقال اطلاعات در سيستم، طراحي Entity Relationship Diagram) ‌‌ERD) يا مدل پايگاه اطلاعاتي رابطه‌اي است. (شكل 9 ) در ‌‌COSMIC جهت انتقال اطلاعات، براساس نياز رويه كاربردي به انتقال اطلاعات تعيين مي‌گردد. مثلا اگر فرض كنيد يك رويه ‌‌‌‌(Functional Process) به گرفتن اطلاعات از بانك اطلاعاتي امانات نياز دارد، شكل 10 را مي‌توان ترسيم نمود. شكل 10- جهت انتقال اطلاعات‌ مرحله آخر وقتي جهت حركت اطلاعات مشخص گرديد، طبق مدل اصلي اندازه گيري (شكل 2) بايد از توابع اندازه‌گيري استفاده نماييم و مجموع اندازه ها را محاسبه كنيم. در اين مرحله ما درقبال يك حركت اطلاعات يك واحد Cfsu را در نظر مي گيريم. در نتيجه 1X data movment (E/X/R/W) = 1 CFSU  مثلا اگر در قسمتي، پنج‌ حركت اطلاعات وجود دارد، پنج واحد‌Cfsu داريم. پس فرمول كلي اندازه‌گيري يك رويه كاربردي را مي توان به صورت زير در نظر گرفت: شكل 11-بانك‌هاي‌ اطلاعاتي‌ مورد نياز اندازه يك لايه نرم‌افزاري را نيز مي‌توان از حاصل جمع اندازه رويه هاي كاربردي‌ ( Functional Process) ‌به دست آورد. پس اگر در لايه نرم‌افزاري ما، دو رويه ‌‌A و ‌B وجود داشته باشد و هر كدام‌ 4Cfsu باشند، اندازه لايه 8‌Cfs مي‌باشد. براي يادگيري هر چه بيشتر اين استاندارد به مثال زير توجه كنيد: در قسمتي از مستندات سيستم كتابخانه ذكر شده، سيستم بايد قادر باشد برگشت كتاب‌ها به كتابخانه و حذف اين كتاب‌ها از فهرست امانات را ثبت كند. شكل 12- مدل اصلي سيستم در ‌‌COSMIC ولي بايد يك ركورد از اين امانت در بانك اطلاعاتي ديگري نيز ذخيره‌گردد تا متصدي كتابخانه بتواند در آينده به آن مراجعه كند. به نظر شما چند‌‌ Cfsu ‌در اين قسمت از مستندات سيستم وجود دارد ( از نظر برنامه‌نويس)؟ جواب: قبل از هر چيز لايه‌هاي نرم‌افزاري را مشخص مي‌كنيم. سپس رويه‌هاي كاربردي و حركت اطلاعات را مشخص و براي حركت هر كدام يك‌‌ ‌Cfsu در نظر مي گيريم. در قسمت اول مسئله گروه هاي اطلاعاتي (‌بانك‌هاي اطلاعاتي ) كه در اين قسمت موردنياز است، مشخص مي كنيم. (‌شكل 11) همان‌طور كه در شكل 11 مشاهده مي‌كنيد، دو بانك‌اطلاعاتي وجود دارد كه براي حذف اطلاعات امانات و افزودن ركورد اطلاعات امانات در تاريخچه امانات مستقيما با آن‌ها در ارتباط هستيم. اگر فرض كنيم دو لايه اصلي ‌‌(Application و RDBMS) در اين نرم‌افزار وجود دارد، مدل ما چيزي شبيه شكل 12 خواهد بود. حال حركات اطلاعات را در اين مدل دنبال مي‌كنيم : - كاربر اطلاعات عضو را وارد مي‌كند. يك حركت از كاربر به لايه اول، در نتيجه:‌ ‌‌.1X Entry - يك خروج اطلاعات از لايه اول به لايه دوم. در نتيجه: 1X Exit. - يك ورود به ‌ ‌RDBMS براي حذف اطلاعات امانات. در نتيجه: 1X Entry. ‌- يك نوشتن در بانك اطلاعاتي امانات ( در واقع حذف را مي توان يك نوع Write ‌دانست). در نتيجه: 1X Write ‌ - يك نوشتن در بانك اطلاعاتي تاريخچه امانات. در نتيجه: 1X Write. - خروج از لايه دوم به لايه اول‌. در نتيجه: ‌‌1X Exit. - ورود به لايه اول. در نتيجه:1X Entry. - خروج از لايه اول و نمايش تاييد حذف اطلاعات به كاربر. در نتيجه: 1X Exit. حال مي توانيم مقادير بالا را در فرمول‌ ‌COSMIC-FFP قرار دهيم و اندازه‌‌ ‌‌ Cfsu را براي اين قسمت از سيستم محاسبه كنيم: = (1+1) + (0) + (1+1+1) + (1+1+Size (Cfsu) of Functional process A= (1 ‌(8Cfsu (COSMIC-FFP v2.2 نتيجه ‌‌8Cfsu شد كه با ذكر نسخه ‌‌COSMIC-FFP استفاده شده در محاسبه نوشته مي شود. حال كه اندازه نرم‌افزار در واحد ‌‌Cfsu به دست آمد، مي‌توانيم اندازه كار مورد نياز براي تهيه اين قسمت از نرم‌افزار را محاسبه كنيم. براي محاسبه كار ‌‌(Effort) به يك عامل ديگر نيز نياز داريم و آن درصد راندمان نيروي كار است. براي محاسبه اين عامل بهترين مرجع را مي‌توان اطلاعات پروژه هاي قبلي دانست. ولي به طور متوسط اين مقدار بين 5/0 تا 7/0 از حداكثر 1 (100 درصد) است. مثلا در پروژهاي قبلي هر برنامه‌نويس براي نوشتن يك‌ ‌20Cfsu ساعت (‌2 روز) وقت صرف كرده‌است. پس اگر همان برنامه‌نويس بخواهد نرم‌افزاري را با مجموع ‌‌‌ 36Cfsu تهيه كند، در 720 ساعت اين نرم‌افزار به اتمام خواهد رسيد. نتيجه‌گيري‌ اندازه‌گيري نرم‌افزار به روش ‌COSMIC-FFP يكي از ساده‌ترين و استانداردترين روش‌هاي موجود در مهندسي نرم‌افزار است. با اين روش مي‌توان بسياري از نرم‌افزارهاي امروزي از وب سايت تا نرم‌افزاري ‌بلا‌درنگ را اندازه گيري نمود. از جمله مزاياي اين استاندارد مي‌توان به آساني، درستي محاسبه و توانايي كار با آن از ابتدايي‌ترين مرحله چرخه توليد نرم‌افزار اشاره كرد. اضافه بر اين، مي‌توان با اين روش حتي قسمت كوچكي از نرم افزار را هم اندازه‌گيري نمود. اگرچه اين استاندار امروزه بسيار مورد استقبال قرار گرفته و بسياري از شركت‌هاي نرم‌افزاري دنيا از آن استفاده مي كنند، برخي از قسمت هاي آن هنوز مبهم به نظر مي‌رسد. از آن جمله مي‌توان از تشخيص لايه‌هاي نرم‌افزاري يا تعيين مرز بين لايه‌ها نام برد كه محاسبه كننده را ملزم به آشنايي كامل با اجزاي تشكيل دهنده نرم افزار قبل از محاسبه مي كند. اشتباه در انتخاب لايه ها و مرز بين آن‌ها باعث خواهد شد اندازه نرم‌افزار به اشتباه محاسبه شود. با اين حال استفاده‌كنندگان از اين استاندارد هر روز بيشتر مي شوند. آموزش اندازه‌گيري نرم افزار با ‌‌COSMIC از سال 2004 در اكثر رشته‌هاي مهندسي نرم‌افزار دانشگاه‌هاي اروپا در كنار روش‌هاي قديمي مثل ‌MKII‌ و ‌COCOMO تدريس مي‌شود و اميد است روزي اين استاندارد جاي خود را به روش‌هاي قديمي متداول بدهد. مطالعه منابع معرفي‌شده نيز به شما كمك خواهد كرد مباني اندازه‌گيري نرم‌افزار با ‌COSMIC-FFP را كه در اين مقاله بحث شد، بهتر ياد بگيريد. ‌ منابع : ‌www.cosmicon.com ‌www.cosmicon.com/overview.asp و ماهنامه شبکه

براى موفقيت يک سازمان به کدام يک از دو مقوله «مديريت» يا «رهبري» نياز داريم؟

يک سازمان براى آنکه به اهداف عالى خود دست يابد بايد به دو مقوله «رهبري» و «مديريت» توجه داشت باشد. چرا که در جهان صنعتى امروز صرفاً برخوردار بودن از مهارتهاى مديريتى براى موفقيت يک مدير کافى نيست، بلکه مديران بايد شناختى اساسى از تفاوت ميان «مديريت» و «رهبري» داشته باشند و بدانند چگونه اين دو فعاليت براى تحقق موفقيت سازمان بايد با هم ترکيب شوند.

منبع : خانه كارآفرينان ايران

در يک سازمان با وجود تفاوت عمده بين «رهبري» و «مديريت»، ارتباط تنگاتنگى بين آن دو وجود دارد؛ يک رهبر مى تواند مدير باشد و يک مدير نيز مى تواند «رهبري» کند. عکس اين قضيه نيز صادق است؛ يعنى يک فرد مى تواند داراى هنر «رهبري» باشد بدون اينکه قادر باشد هدفهاى سازمانى را تحقق بخشد (مدير نباشد) و يا اينکه يک فرد ممکن است مدير منظمى باشد ولى کارکنان از روى ترس و اجبار وظايف خودشان را انجام دهند (رهبر نباشد.)

در اين نوشتار سعى داريم به اين سئوال پاسخ دهيم که براى موفقيت يک سازمان به کدام يک از دو مقوله «مديريت» يا «رهبري» نياز داريم؟

تعريف رهبرى

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

«رهبري» را اصولاً «هنر نفوذ در ديگران» مى دانند. بدين معنى که پيروان به دلخواه نه از روى اجبار، از رهبر اطاعت مى کنند.

بنابراين، منظور از رهبرى به طور عام، تأثير گذارى بر افراد و انگيزش آنان به طورى است که از روى ميل، علاقه و با اشتياق براى دستيابى به هدف هاى گروهى تلاش کنند.

تعريف مديريت

فرآيند برنامه ريزي، سازماندهي، هدايت و نظارت بر کار اعضاى سازمان و کاربرد کليه منابع قابل دسترسى براى رسيدن به هدفهاى تعيين شده سازمان را «مديريت» مى گويند.

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

تفاوت مدير و رهبر

بسيارى از مديران سازمان ها، از تفاوت ميان رهبرى و مديريت آگاهى ندارند و همين امر باعث مى شود که در اجراى وظايف سازمانى خود ، به اشتباه عمل کنند.

رهبرى همان مديريت نيست. اگر چه بسيارى از مديران رهبرند و بسيارى از رهبران مدير، ولى فعاليت هاى رهبرى و مديريت فعاليت هاى يکسانى نيست.

بايد توجه داشت که «مديريت» با «رهبري» تفاوت هاى عمده اى دارد که بايد مديران در اجراى وظايف خود به اين تفاوت ها توجه داشته باشند، براى آشنايى مديران، به چند مورد از تفاوت هاى يک «مدير» با يک «رهبر» در يک سازمان اشاره مى کنند:

1- مديران در پست خود منصوب شده اند. آنان قدرت قانونى دارند که اجازه مى دهد در مواقع ضرورى به ديگران پاداش دهند يا آنان را تنبيه کنند. در حالى که يک رهبر ممکن است منصوب شده و يا از درون گروه پديد آمده باشد و اين اجازه را نداشته باشد که در مواضع ضرورى ديگران را تشويق يا تنبيه کند چرا که قدرت قانونى ندارد.

2- توانايى تاثيرگذارى مديران بر افراد سازمان، بر مبناى اختيار رسمى است که از پست سازمانى آنها ناشى شده است در حالى که رهبران مى توانند بر عملکرد ديگران تاثير بگذارند بدون آنکه قدرت تاثيرگذارى آنان از اختيار رسمى ناشى شده باشد.

3- مدير اداره مى کند در حالى که رهبر ابداع مى کند.

4- «مديريت» يک رونوشت است در حالى که «رهبري» يک اصل است.

5- مدير امور را نگهدارى مى کند در حالى که رهبر آنها را بهبود مى بخشد.

6- مدير روى سيستمها و ساختار تمرکز دارد ولى رهبر روى افراد تمرکز مى کند. در واقع مديريت به فرآيندهاى سازمانى توجهى حساب شده دارد در حالى که رهبرى به کارکنان به عنوان افراد انسانى توجه واقعى دارد.

7- مدير از اجراى يک شغل اطمينان حاصل مى کند، در حالى که رهبر مراقب فردى است که آن شغل را اجرا مى کند و به او توجه دارد.

8- مدير نظارت مى کند، ولى رهبر اعتماد مى پراکند.

9- مدير ديدگاه محدودى دارد، ولى رهبر از ديدگاه وسيعى برخوردار است.

10- مدير «چگونه و چه وقت» را مى پرسد، در حالى که رهبر «چه چيز و چرا» را مى پرسد.

11- مدير نظر به انتهاى خط دارد، ولى رهبر چشم به افق دارد.

12- مدير پيروى مى کند، در حالى که رهبر سرچشمه مى گيرد.

13- مدير وضع موجود را مى پذيرد، ولى رهبر با وضع موجود در جدال است.

14- مدير سرباز قديمى خوبى است، اما رهبر آدم خودش است.

15- مدير کارها را درست انجام مى دهد، در حالى که رهبر کارهاى درست را، انجام مى دهد.

برخى از خصوصيات عمده براى رهبران موفق

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

از جمله خصوصيات عمده اى که براى رهبران ذکر مى شود، مى توان به موارد زير اشاره کرد:

1- هوش: تحقيقات انجام شده بر روى رهبران موفق سازمانى نشان مى دهد که هوش آنان از ميانگين هوش پيروان و زيردستانشان بيشتر است.

2- خصوصيات ظاهرى و فيزيکى مانند قد، سيما و حرکات دست.

3- بلوغ اجتماعى و وسعت ديد: رهبران از جهت عاطفى با ثبات و داراى اعتماد به نفس اند و نسبت به مسايل و رويدادهاى اطراف خود ديد و بينش وسيعى دارند.

4- رهبران شخصيت برونگرا دارند.

5- انگيزه هاى توفيق طلبى و نيل به هدف: رهبران داراى انگيزه هاى قوى براى موفقيت هستند و توفيق طلب اند.

6- خصوصيات شغلى مانند پشتکار و تلاش و ابداع و ابتکار.

7- خصوصيات اجتماعى مانند مرتب اجتماعى و سياسى.

8- انسانگرايى: انسانگرايى و تاکيد بر ارزش انسانها خصوصيت بارز ديگر رهبران موفق است.

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

مهارتهاى مورد نياز مديران

مديران در هر سطحى که باشند و در هر نوع سازمانى که فعاليت کنند بايد به مهارتهاى خاصى مجهز شوند تا بتوانند در نيل به اهداف تعيين شده سازمان را يارى رسانند. اين مهارتها عبارتند از: مهارتهاى ادارکي، مهارتهاى انسانى و مهارتهاى فنى.

1- مهارتهاى ادارکى: اين مهارتها توانايى هماهنگى کردن و وحدت همه فعاليت هاى سازمان را به مدير مى دهند تا بتواند سازمان را به صورت يک کل در محيطى که آن را احاطه کرده است مشاهده، و روابط متقابل بخشهاى مختلف و چگونگى تاثير تغيير هر قسمت در کل سازمان را پيش بينى کند.

مهارتهاى ادارکى توانايى تحليل موقعيت و تعيين ريشه مسايل و تدوين برنامه مناسب را به مدير مى دهند. اين مهارتها خصوصاً براى مديران عالى سازمان که بايد اهداف وسيع و برنامه هاى بلند مدت سازمان را براى آينده طرح ريزى کنند، ضرورى است.

2- مهارتهاى انسانى: اين مهارتها به مدير امکان مى دهند تا با افراد، در کنار آنها و به طور موثر با آنها کار کند. مديران در همه سطوح به اين مهارت نياز دارند، چون براى نيل به اهداف سازمان به افراد داخل و خارج سازمان وابسته اند. مديرانى که مهارتهاى انسانى خوبى دارند مى توانند نيازها و انگيزه هاى افراد را درک و آنان را تشويق کنند تا بدون نگرانى در تصميم گيرى ها مشارکت داشته باشند.

3- مهارتهاى فنى: اين مهارتها به معنى توانايى به کار بردن ابزار، شيوه ها و دانش مورد نياز براى اجراى يک زمينه تخصصى است.

وظايف مدير

براى يک مدير، وظايف متنوعى عنوان شده است، اما در حالت کلى مى توان وظايف يک مدير را به صورت زير خلاصه کرد:

1- برنامه ريزى: مدير اهداف سازمان در درجه اول تعريف مى کند سپس با تعيين راهبرد تحقق اين اهداف و ايجاد مجموعه اى از برنامه ها براى يکپارچه و هماهنگ کردن فعاليت در جهت نيل به اين هدف ها گام بر مى دارد.

2- سازماندهى: مدير مشخص مى کند که در يک سازمان چه وظايفى بايد اجرا شوند و چه کسانى بايد اين وظايف را انجام دهند. وظايفى که مى توانند با هم يک گروه شغلى تشکيل دهند، تعيين مى شوند.

3- هدايت: مدير فعاليت هاى افراد سازمان را هدايت مى کند و آنها را هماهنگ مى کند و با ايجاد انگيزه در زيردستان فعاليت هاى آن را جهت مى دهد، موثرترين مجارى ارتباط را انتخاب و تعارض ميان اعضاى سازمان را بر طرف مى کند.

4- نظارت: مدير براى اطمينان از اجراى درست و به موقع همه کارها عملکرد سازمان را ارزيابى مى کند و عملکرد واقعى سازمان را با هدفهايى که از قبل تعيين شده بود، مقايسه مى کند تا اگر انحراف هايى از برنامه هاى تعيين شده مشاهده شد، آنها را اصلاح کند.

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

نتيجه گيرى:

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

روش تخمین باFP

سلام

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

روش FP

سیتم مورد نظر:نمایش کارنامه کلی سایت دانشگاه شریعتی

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

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

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

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

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

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

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

-          خروجی های سیستم : 1 گزارش از کارنامه کلی دانشجو می باشد.

-          تعداد در خواست ها : 3

-          تعداد فایل ها که می تواند تعداد جداول در دیتا بیس باشد 2 عدد در نظر گرفته شده

-          تعدا رابط های خارجی: 3 می باشد.

برای محاسبه ی FP اطلاع از موارد فوق الزامی می باشد.

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

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

 

بعد از ترتیب دادن جدول فوق باید به 14 سوال زیر به دقت پاسخ دهیم.

1-       آیا سیستم نیازمند تهیه مکانیزم پشتیبانی و احیاء قابل اعتماد است؟

2-       آیا انتقال اطلاعات مورد نیاز است؟

3-       آیا توابع پردازش توزیع شده وجود دارد؟

4-       آیا کارایی، مسئله بحرانی است؟

5-       آیا سیستم در محیط عملیاتی موجود و پر استفاده اجرا می شود؟

6-       آیا سیستم نیازمند ورود داده ها بطور همزمان است؟

7-       آیا ورود همزمان داده ها نیازمند ایجاد تراکنشی بر روی چندین صفحه عملیاتی است؟

8-       آیا فایل های اصلی مستقیما به روز آوری می شوند؟

9-       آیا ورودی ها ، خروجی ها، فایل ها یا درخواستها پیچیده اند؟

10-   آیا پردازش داخلی پیچیده است؟

11-   آیا کد طراحی شده باید قابل استفاده مجدد باشد؟

12-   آیا تبدیلات و نصب در طراحی منظور شده اند؟

13-   آیا سیستم برای نصب در چندین محل وسازمان متفاوت طراحی شده است؟

14-   آیا این کاربرد طراحی شده است تا تغییرات را سهولت ببخشد؟

هر یک از این سوالات از مقیاسی بین صفر(بدون اهمیت) تا 5(خیلی ضروری) پاسخ داده می شود. و بعد با هم جمع می شود تا F_i ∑ که برابر N  است ، بدست آید.

برای مسئله فوق بعد از محاسبات عدد 43  بدست آمده است.

بعد باید با ارقام بدست آمده مقدار C  یا Comlexity Multiplier را بدست آوریم.

(C=(0.65+0.01×N

که در آن N  همان F_i ∑ می باشد که مقدار آن برابر 43 است.یعنی داریم:

C=(0.65+0.01×43)=1.08

بعد از محاسبه میزان پیچیدگی (C) محاسبه نهایی جهت بدست آوردن Function Points (FP) یا همان نقاط  عملکرد را در فرمول نهایی زیر جایگزاری می کنیم.

FP=∑ (Count × weight)×C

که مقدار  ∑ (Count × weight) قبلا در جدول محاسبه شده است. پس داریم:

59×1.08=63.72

تخمین زمان تکمیل پروژه و هزینه آن

تخمين زمان تكميل پروژه و هزينه هاي آن

 

برآورد هزينه:

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

كاري از دست هيچ كس برنمي آيد. پروژه با شكست مواجه شده و اكنون نه تنها اين افراد نمي توانند هزينه فروش نرم افزار را در اختيار بگيرند، بلكه بايد به فكر جريمه ديركرد آن نيز باشند.

در راستاي معرفي كتابهاي نرم افزاري كه بعدا به اجمال توضيح داده خواهد شد، جلد دوم كتاب دكتر سعيد پارسا با عنوان مهندسي نرم افزار، چگونگي برآورد هزينه نرم افزار را به روشني بيان نموده است.

در اين كتاب آمده است:

هدف از برنامه ريزي ايجاد چهارچوبي براي مدبريت جهت هزينه يابي و زمانبندي پروژه هاي نرم افزاري است . برنامه ريزي با تخمين منابع ، هزينه و برنامه كاري انجام مي گردد . لازمه تخمين دقيق تجربه خوب كاري است . لذا ، بناء پروژه بر اساس تخمينهاي اوليه با ريسك همراه است . با افزايش ريسك عدم اطمينان از برنامه ريزي اوليه افزايش مي يابد . با افزايش پيچيدگي و اندازه پروژه ها ميزان عدم اطمينان بيشتر مي شود . ميزان پيچيدگي را بر اساس معيارهاي سنجش وظيفه و FP مي توان مشخص نمود .

تخمين پروژه نرم افزاري

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

قبل از تخمين هر گونه هزينه اي بايد حوزه عملكرد پروژه مشخص شود و اندازه تخميني آن تعيين گردد. معمولا ، حوزه عملكرد پروژه را مي توان با يك پاراگراف بيان كرد . براي تخمين هزينه مي توان عمليات سيستم را بر اساس وظايف ، يا بر اساس امور و يا براساس كلاسهاي اشياء مورد نياز به واحدهاي كوچكتري تجزيه نمود. سپس براي هر واحد مي توان مقادير LOC و FP را محاسبه كرد. قابليت توليد و يا باروري را بر اساس Fp/pm يا Loc/pm تعيين نمود .

تخمين بر چه اساسي انجام مي گيرد؟

•  تخمين بر اساس تعداد خطوط: يكي از معيارهاي ارزيابي كمي نرم افزار ، اندازه آن است . اندازه نرم افزار را معمولا" با تعيين تعداد خطوط برنامه هاي مربوطه مشخص مي كنند . مثلا بر همين اساس، در سيستمي بر اساس معيارهاي كمي، نكات زير مطرح است:

 i. تعداد متوسط خطا در هر هزار خط برنامه

 ii. تعداد متوسط نقص در هر هزار خط برنامه

 iii. هزينه براي هر خط برنامه

 iv. تعداد متوسط صفحات در هر هزار خط برنامه

 v. تعداد متوسط خطا در مقايسه با نفر ساعت

 vi. تعداد متوسط سطر در مقايسه با نفر ساعت

 vii. هزينه در مقايسه با تعداد صفحات مستندات

اكنون تعداد خطوط لازم كد برنامه براي براي انجام هر وظيفه را بايد مشخص نمود . براي اين منظور حداكثر ، حداقل و متوسط تعداد خطوط لازم را مشخص نموده و تعداد تخميني خطوط لازم يا در اصطلاح LOC را از رابطه زير مي توان مشخص كرد:

6 / ( حداكثرخطوط + 4 * متوسط خطوط + حداقل خطوط ) = تعداد خطوط لازم

 

•  تخمين بر اساس وظيفه:

  ميزان وظيفه مندي براي نرم افزارهاي تجاري معمولا براساس اطلاعات و داده ها در حوزه مساله محاسبه مي شود.

•  تخمين براساس فرآيند نرم افزار:

 كار تخمين پروژه هاي نرم افزاري را به تخمين وظايف در مراحل چرخه حيات يا مراحل فرايند توليد نرم افزار مي توان افراز نمود. ميزان تلاش و كار لازم براي انجام هر فعاليت از وظايف تعيين شده معمولا" بر اساس كارايي نفر در ماه مشخص مي شود. ممكن است هزينه افراد بر اساس نوع وظيفه محوله متفاوت باشد. معمولا" به تحليلگران با سابقه دستمزدي بيشتر از برنامه نويسان تعلق مي گيرد.

*** *** ***

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

 

در رابطه با  تخمين بيشتر بدانيم:

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

پس بهتر است كه بعد از مراحل اوليه تهيه چارت سازماني، مصاحبه و جمع آوري اطلاعات و خواسته هاي مديران ارشد(كارفرمايان)، با روش هاي شناخته شده و گاه تجربي خودمان، به سراغ تكميل پروژه برويم. اما چگونه بايد زمان تحويل پروژه را به كارفرمايان قول داد؟ آيا بيان تاريخ دقيق تحويل خوب است؟ مثلا عباراتي مانند " قول مي دهم پروژه شما در 1/6/1385 حتما آماده شود"

در زير به اين موضوع كارشناسانه تر مي پردازيم:

از سري مقالات مجله علم الكترونيك و كامپيوتر- شماره 314 دي ماه 1382- با اندكي تغيير

ارزيابي پروژه در سه گام:

ارزيابي كار پروژه سه بخش دارد:

First cut اوليه كه عموما به عنوان يك برآورد اوليه شناخته مي شود، رديابي تخمين در مقابل اعداد واقعي و استفاده از برنامه زماني براي اينكه ببينيم چه اتفاقي براي پروژه رخ خواهد داد. اگر تخمين هايتان را زده ايد يا اينكه چندان به واقعيت نزديك نيستيد، عصباني نشويد. اين تكنيك ها را براي يادگيري و انجام تخمين بكار ببريد.

 

بخش1: يك تخمين اوليه انجام دهيد:

اگر مدير پروژه هستيد، احتمالا تلاش مي كنيد تا كار را در ابتداي پروژه برآورد كنيد، حتي اگر تاريخ نهايي پروژه را اعلام كرده باشيد. برخي اوقات مديران ارشد(كارفرمايان) در شنيدن تخمين شما ممكن است مشكل داشته باشند. يكي از اين سه جايگزين را براي انجام تخمين  كل پروژه استفاده كنيد:

‌أ) مقدار زمان را براي تخمين تهيه كنيد: ما قادر خواهيم بود تا بين ماه مه و 15 ژوئن آن را آماده ارائه كنيم. برخي مديران ارشد، بخش دوم گفتار شما را نمي توانند بشنوند، آنها ممكن است فقط يكم ماه مه را بشنوند. اگر براي مديري شبيه آن كار مي كنيد، دو پيشنهاد ديگر ذيل را امتحان كنيد.

‌ب) براي تشريح دقت تخمين، از كلمه حدودا استفاده كنيد: پنج نفر براي مدت 9ماه يا 10نفر براي مدت حدودا 6ماه. شما تاريخ نهايي را مشخص نكرده ايد، ولي نيروهاي مورد نياز را شرح داده ايد.

‌ج) يك سطح اطمينان براي شرح زمانها تهيه كنيد: دادن اطمينان 90% در اول ژوئن و 100% در اول آگوست.

بنا بر تجربه، حتي مديراني كه كلمه بين را نمي شنوند، سطح اطمينان را مي توانند بشنوند.

ابتدا كه يك تخمين ناخالص براي پروژه داريد، مي توانيد تمرين كنيد و براي تمام اجزاي پروژه برآورد داشته باشيد. خواه تلاش كنيد تا تخمين خلاصه اي فراهم كنيديا با بي دقتي عمل كنيد و با تخمينهاي تكميل نشده سروكار داشته باشيد، به هرحال چند تخمين كلي براي پروژه خواهيد داشت.

مشكل اين برآوردها اين است كه تنها حدسيات مي باشند. آنها بهترين حدسياتي هستند كه مي شود زد. ولي هنوز در حد احتمال هستند. زمانيكه پروژه آشكار مي شود، قادر خواهيد بود تا بازخورد را محاسبه كنيد و ببينيد تا چه حد بخش دوم برآوردتان EQF يا عامل كيفيت برآورد، صحيح بوده است.

 

بخش2: EQF را براي درك برآورد پروژه رديابي كنيد:

زمانيكه به مديريت پروژه ادامه مي دهيد، تخمين تاريخ تكميل اوليه خود را دنبال كنيد. هر ماه (يا در يك پروژه كوتاه، هر هفته) چند دقيقه از زمان خود را به نشست و پرسش اعضاء پروژه اختصاص دهيد. فكر مي كنيد چه زماني پروژه را تمام خواهيم كرد؟ آن برآورد را در يك نمودار كه تاريخ اتمام در محور Y و تاريخي كه در آن سوال را مي پرسيديد در محور X، رديابي كنيد.

براي پرسيدن سوال دو دليل خوب وجود دارد.

اول، شما به تمركز بر روي كاركنان پروژه براي تكميل آن ادامه مي دهيد. افراد به كارهايي كه شما به عنوان مدير پروژه بر روي آنها تمركز مي كنيد، تمايل دارند.

دوم، با پرسش از كاركنان پروژه، مي توانيد تاريخ تكميل را بيابيد. وقتي به بخش EQF مي نگريد، متوجه مي شويد كه اگر پروژه در تاريخ معين شده انجام نشود، براي افراد اهميتي دارد يا اينكه آنها نسبت به تاريخ ارائه شده براي اتمام پروژه اطمينان دارند يا خير. سپس مي توانيد به نگرانيهاي آنها ويا خود بپردازيد.

زمانيكه به همراه اعضاي پروژه، EQF را رديابي مي كنيد. چيزهاي بيشتري درباره پروژه مي آموزيد و از EQF استفاده مي كنيد تا بدانيد كه تخمين اوليه شما تا چه حد خوب بوده است.

 

بخش3: ازEQF براي مديريت موارد نگراني پروژه بهره ببريد:

از پستي و بلنديهاي EQF براي طرح پرسش هايي نظير: به من بگو چه اتفاقي براي پروژه رخ داده كه باعث شده شما فكر كنيد ما در تاريخ معين شده، تكميل مي كنيم؟/غلبه مي كنيم؟/تكميل نمي كنيم؟، زمانيكه افراد خوشبين تر يا بدبين تر مي شوند، مي خواهم بدانم دليلش چيست؟

EQF نه تنها بازخورد تخمين اوليه را نشان مي دهد، بلكه تكنيك بحث كردن درباره وضعيت پروژه با اعضاي آن را نيز به ما  مي دهد. در زمانيكه نگرانيهاي اعضا پروژه را درك كنيم، مي توانيم به آنها رسيدگي كنيم يا به مديريت منتقل كنيم.

اگر شما تنها يكي از اين تكنيك ها را براي تخمين و مديريت پروژه خود بهره مي بريد، افزودن دو تكنيك ديگر را نيز درنظر بگيريد. تكميل هر پروژه اي همراه با مسائل غير قابل پيش بيني است. EQF تكنيك برجسته اي براي نمايش امور غير قابل پيش بيني و دانستن دليل عدم اطمينان اعضاء به پروژه مي باشد. هرچه افراد درباره پروژه بيشتر بدانند، مديريت پروژه بهتر خواهد بود و شما نسبتا به تخمين اوليه نزديك خواهيد شد. حداقل درخواهيد يافت كه تا چه حدي برآورد اوليه شما از مرحله پرت است و چرا. و آن اطلاعات مي توانند شما را در پروژه بعدي ياري كنند.

http://swengineering.persianblog.ir   

تخمین هزینه و زمان در پروژه های نرم افزاری!

---

 

تخمین هزینه و زمان در پروژه‌های نرم‌افزاری

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


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



پس نخست باید اطلاعات ضروری آماده شود. نگارنده این اطلاعات را در سه دسته تقسیم کرده است:

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

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

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

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

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

همان طور که گفته شد روش‌های مختلفی برای تخمین و برآورد حجم فعالیت‌های لازم برای انجام یک پروژه نرم‌افزاری معرفی شده است. معروف‌ترین آن‌ها روش COCOMO است. از آن‌جا که قصد این نوشته تشریح این روش نیست فقط به بيان این نكته بسنده می‌شود که در این روش اساسا میزان خطوط کد لازم برای تولید برنامه بر اساس مفهوم Function point تخمین زده شده و بر اساس آن حجم فعالیت‌های لازم برای پروژه تخمین زده می‌شود.

با فرض این‌که نیازهای سیستم در قالب یوزکیس‌ها شناسایی شده اند، متخصصین RUP نیز روش‌های گوناگونی را برای تخمین هزینه و برآوردهای واقع بینانه پروژه ارايه کرده‌اند. روش دیگری که در میانه‌ي دهه‌ي 1990 ارايه شد روش Use Case Point است. در این روش با تعریف Use Case Point های سیستم و تخصیص نفر ساعت لازم برای پیاده‌سازی آن‌ها حجم فعالیت لازم تخمین زده می‌شود. هر یوزکیس شامل سناریو یا سناریوهایی است. علاوه بر UseCaseهای سیستم واسطه‌های ارتباطی یوزکیس با دنیای بیرون ازجمله برای مثال پنجره‌های ویندوز و یا صفحات وب نیز وجود دارند که طراحی و پیاده‌سازی آن خود حجم کار قابل توجهی را می‌طلبد. بنابر این قدم اول تشخیص یوزکیس‌ها و تشريح سناريوهای آن‌هاست. فرآیند تشخیص و تشریح یوزکیس‌های سیستم هر چه با دقت بیش‌تری انجام شود، برآوردهای واقعی‌تری را منتج خواهد بود. اما همان‌طور که کارشناسان RUP به خوبی می‌دانند، یوزکیس‌ها به عنوان مدلی از فعالیت‌های سیستم به طور كامل انتزاعی بوده و بسته به آن‌که چه کسی و از چه زاویه‌ای آن‌ را می‌نویسد سطوح و پیچیدگی‌های مختلفی می‌توانند داشته باشند. برای مثال می‌توان صدور چک را یک یوزکیس تلقی کرد و هم‌زمان می‌توان صدور چک را زیرسیستمی معرفی نمود که خود شامل تعداد مشخصی یوزکیس است. نتیجه آن که سطوح یوزکیس‌ها می‌توانند مختلف باشند و بنابراین در تعیین تعداد یوزکیس پوینت‌ها باید دقت بیش‌تری مبذول نمود. به هرحال بهتر است که سطوح انتزاع در تمامی سیستم از یک روال ثابتی پیروی کند، در غیر این صورت باید ضریب سطح انتزاع نیز در معادلات مربوط به Use Case Point در نظر گرفته شود


یوزکیس پوینت روشی در ارزیابی و تخمین هزینه و زمان پروژه های نرم‌افزاری

قبل از تشریح دقیق‌تر این روش اصطلاحات خاص این روش را بهتر بشناسیم:

آن‌چه خواننده باید بداند:

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

2. ساختار یوزکیس‌ها از سازمان به سازمان و از پروژه به پروژه متفاوت است. چیزی که اساسا در تخمین و ارزیابی موثر است. این نوشته بر مبنای ساختار ارايه شده توسط Allister Mac Lin در کتاب How To Write Effective Use Case نوشته شده است. مطالعه این کتاب را به خواننده توصیف می‌کنیم.


محدوده:
این مقاله صرفا در مورد درکUse Case Point بوده و اطلاعاتی درمورد نحوه نوشتن یوزکیس‌ها به خواننده نمی‌دهد. نوشته‌ها و مقالات بسیاری در این باب نوشته شده و در اینترنت نیز قابل دسترس است.
تاریخچه:

روش Use Case Point مبتنی بر کارustav karner که در سال 1993 به عنوان تز دانشگاهی ارايه شد. این روش امروزه به عنوان روش تخمین زمان و هزینه در برخی از ابزارهای مهندسی نرم‌افزار که از UML برای مدل‌سازی استفاده می‌کنند، پیش‌بینی شده است که از آن جمله می‌توان به ابزار نرم‌افزاری خوش‌دست Sparx System Enterprise Architect اشاره کرد.


مراحل روش یوزکیس پروینت برای تخمین


1. تعیین UAW) Unadjusted Actor Weight ): اولین قدم دسته‌بندی همه بازیگران سیستم است. در جدول زیر دسته‌بندی بازیگران آمده است. ستون دوم راهنمای تصمیم گیری در مورد نوع بازیگر بوده و نشان میدهد که بازیگر باید در کدام دسته قرار می‌شود. آخرین ستون نیز عامل پیچیدگی آن را نشان می‌دهد.

2. تعیین UUCW ( Unadjusted Use Case Point ). مرحله دوم شمارش یوزکیس‌ها و تعیین وزن آن‌ها بر حسب تعداد سناریوها و تعداد تراکنش‌های آن‌هاست.

3. تعیین مجموع UUCP (Unadjusted Use Case Point ): برای محاسبه این مقدار از فرمول روبه‌رو استفاده می‌شود: مجموع UAW + مجموع UUCW = UUCP

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





1. محاسبه فاکتور تکنیکی

برای محاسبه فاکتور تکنیکی پروژه از معادله Tfactor =T1 +T2 + …….T12+T13 استفاده می‌گردد.

2. محاسبه ميزان پيچيدگي تكنيكي پروژه:

میزان پیچیدگی تکنیکی پروژه با فرمول TCF= 0.6 +(0.01* Tfactor)محاسبه می‌شود.


3. عامل محیطی:

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

4.مجموع عوامل محیطی از جمع مقادیر بالا محاسبه می‌شود:

یعنی:Efactor=SUM(e1….e8)

5.برای محاسبه ضریب عامل محیطی از معادله EF=1.4+(-0.03 * Efactor)استفاده می‌شود.

6. د رنهایت مقدارAUCP (Adjusted Use Case Points ) با استفاده از فرمول زیر محاسبه می‌شود؛ یعنی AUCP=UUCP * TCF * EF

با ضرب مقدار به دست آمده در نفر ساعت لازم برای انجام هر یوزکیس پوینت نفر ساعت کل لازم برای انجام پروژه به دست می‌آید. برای میزان نفر ساعت لازم برای هر Use Case Point مقادیر متفاوتی پیشنهاد شده از جمله 10، 15 و 20 و حتا 30 تا 40 نفر ساعت برای هرUse Case Point در نظر گرفته شده است. با این همه بعضی از متخصصان بیان کرده‌اند که این عدد خود به فاکتورهای محیطی مرتبط است. تجربه عملی نگارنده نشان داده که میزان 10 تا 15 نفر ساعت در محیط‌های کاری ما مناسب است.


مثال عملی برای تخمین زمان یک پروژه

برای نشان دادن چگونگی تخمین هزینه یک پروژه از یک مثال ساده استفاده می‌کنیم. ابتدا حوزه مساله:

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

- کد مشتری

- نام مشتری

- آدرس مشتری

- تلفن مشتری

- اطلاعات معتبر کارت اعتباری مشتری

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

- کنترل یکتایی کد مشتری

- کد مشتری نباید از 8 حرف و عدد بیشتر باشد

- کنترل کارت اعتباری مشتری باید از طریق ارتباط سیستم با سیستم کارت خوان بانک بصورت اتوماتیک انجام شود

- طول شماره کارت اعتباری نباید بیش از 10 حرف یا عدد باشد

- اپراتور باید بتواند اطلاعات مشتری جدیدی را اضافه کرده و اطلاعات مشتری موجود را تغییر داده ویا آنرا حذف کند

- بانک اطلاعاتی در دفتر اطلاعات شرکت نصب شده و تنها ورود و ویرایش و حذف اطلاعات توسط اپراتور سیستم انجام میشود

- نرم افزار در میحیط ویندوز اجرا خواهد شد و سیستم عامل ویندوز XP به اینمظور استنفاده خواهد شد

یوزکیس ورود اطلاعات مشتری در سیستم مشتریان شرکت راپیران

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



تراکنش یوزکیس:تراکنش یوزکیس، واحد مجموعه فعالیت‌هایی است که به طور کامل انجام می‌شود. برای تشخیص تراکنش یوزکیس باید دید که آیا تراکنش ارزشی تولید می‌کند. در صورتی که یک فعالیت ارزشی را تولید نمی‌کند نباید آن را به عنوان تراکنش یوزکیس در نظر گرفت؛ برای مثال این‌که کاربر کامپیوتر خود را روشن می‌کند و یا این‌ که کاربر روی کلید ایجاد مشتری و یا هر کلید دیگری در پنجره ارتباطی خود کلیک می‌کند تراکنش محسوب نمی‌شود، اما کارت اعتباری مشتری توسط یک تراکنش کنترل اعتبار بررسی می‌گردد. تعدادUse Case Point ها به طور كامل بستگی به چگونگی تعریف بازیگران و تراکنش‌های تعریف شده دارد . بنا براین تشریح وتوصیف یوزکیس ها باید ازطریق الگوها و سرخطهای مشخصی انجام شود . بهترین راه برگزاری جلسه با تمامی اعضای تیم مسئول انجام پروژه قبل از نوشتن شرح یوزکیس است. عمق تشریح یوزکیس می‌تواند تا 40 درصد روی تخمین انجام شده تاثیر گذار باشد. روش و الگویی که در این‌جا ارايه می‌شود، تنها الگو نبوده و تنها برای تشریح مساله‌ي بالا ارايه شده است.

كاربرد همزمان روش المانهاي مرزي و المانهاي محدود در تحليل محيطهاي پيوسته

هر يك از روشهاي عددي داراي مزيتها و محدوديتهايي مي‌باشند كه استفاده از آنها را در پاره‌اي از مسائل مشكل و يا غيرممكن مي‌سازد. روش FD بر اين اساس استوار است كه مشتقات حاكم در معادلات ديفرانسيل جزئي بصورت معادلات تفاضلي نوشته مي‌شوند. از نظر كاربرد بسيار ساده بوده ولي در مسائل با مرزهاي ناهموار و يا تغييرات سريع متغيرها غيرقابل كاربرد و يا نامناسب مي‌باشد. در روش FE ميدان به المانهاي محدودي تقسيم‌بندي شده و رفتار هر المان برحسب معادله ديفرانسيل حاكم بيان مي‌شود. با جمع‌بندي اين المانها و اعمال شرايط تعادل و سازگاري بين آنها به يك دستگاه معادلات جبري خواهيم رسيد. اين متد يكي از قويترين و كاربردي‌ترين روشها براي حل عددي انواع مسائل خطي يا غيرخطي با هندسه پيچيده و يا مسائل ديگر مي‌باشد. در مورد روش BE، معادلات ديفرانسيل حاكم به فرمهاي انتگرالي روي مرزها تبديل شده و با تقسيم مرز به المانهاي مرزي اين انتگرالها بصورت عددي حل مي‌شوند. اين روش براي ميدانهايي كه مرزها هندسه پيچيده داشته و يا متغيرها سريعا در روي مرز تغيير مي‌كنند و همچنين براي مسائل با دامنه‌هاي بيكران بخوبي قابل كاربرد است . با توجه به خصوصيات هر يك از اين روشهاي عددي، كه هر يك نتايج دقيقتر در نوع خاصي از مسائل را بدست مي‌دهند، مي‌توانيم آنها را با همديگر تركيب كنيم. بعنوان مثال وقتي يك سازه با خاك را مدل مي‌كنيم ميدان مربوط به خاك يك ميدان نيمه بيكران خواهد بود و بهتر است با روش المان مرزي كه نتايج دقيقتري را داشته و در عين حال از متغيرهاي كمتري استفاده مي‌كند، مدل شود و در عوض سازه را مي‌توان با روش المان محدود مدل نمود. حال اين دو ميدان با فرمولبندي‌هاي متفاوت را مي‌توان با يكديگر كوپل كرده و مسئله را حل كرد. در بسياري از مسائل اندركنش سازه - خاك و يا اندركنش سازه - آب و يا دو ميدان با رفتارهاي خطي و غيرخطي، مي‌توانيم از روش كوپل براي بهبود بخشيدن به نتايج و در عين حال كاهش تعداد معادلات استفاده كنيم. از روش كوپل مي‌توان براي بدست آوردن نتايج دقيقتر در قسمتي از ميدان استفاده كرد. براي مثال روش المان مرزي در نقاط تمركز تنش و يا بارهاي نقطه‌اي نتايج بهتري از روش المان محدود را دارد. در اين پايان‌نامه بر روي كوپل كردن دو روش بسيار قوي FE و BE كه كاربرد فراواني در حل مسائل مهندسي دارند بحث شده و روابط حاكم بر آن و روشهاي انجام اين كار آورده شده‌اند. برنامه كامپيوتري به زبان فرترن براي مسائل الاستيسيته صفحه‌اي جهت كاربرد همزمان روش المان محدود و المان مرزي نوشته شده است . مثالهايي نيز جهت بررسي مزيتهاي اين روش با استفاده از برنامه حل گرديده و با روشهاي ديگر و با حلهاي دقيق محاسبه شده‌اند. http://dbase.irandoc.ac.ir/00060/00060167.htm

مناسب‌ترين روش براي توليد نرم‌افزارهاي كوچك

اشاره : در حقيقت ساختن يك نرم‌افزار فقط نوشتن كدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي كاربران گرفته تا طراحي، نوشتن كد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي كوچك با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي كوچك نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با كيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمركز استفاده كند. با استفاده از تكنيك‌هايي مفيد، از روش‌هايي مانند XP،Scrum و RUP مي‌توان رويه‌اي مناسب براي توليد نرم‌افزارهاي كوچك به‌وجود آورد. همچنين مي‌توان از روش‌هايPSP و TSP نيز كه براي توليد نرم‌افزارهاي كوچك مناسب هستند استفاده نمود و به‌وسيله اين روش‌ها كيفيت و قابليت‌هاي نرم‌افزارها را بالا برد و در حداقل زمان ممكن نرم‌افزار را تهيه نمود. اين مقاله با بررسي روش‌هاي جديد و متداول امروزي در توليد نرم‌افزار، بهترين و مناسب‌ترين روش توليد نرم‌افزارهاي كوچك را به شما نشان خواهد داد.   فرايند توليد نرم‌افزار پيروي از يك رويه منظم توليد نرم‌افزار به توليدكنندگان نرم‌افزار كمك مي‌كند امور مربوط به‌توليد نرم‌افزار را منظم و پروژه را در حداقل زمان ممكن و با كارايي بالايي انجام دهند. در حقيقت يك رويه يا Process از مراحل مختلفي تشكيل شده است. اين مراحل فعاليت‌هاي مربوط به رويه را مشخص مي‌نمايند و تعيين مي‌كنند كه اين فعاليت‌ها بايد چگونه انجام شوند. پيروي از اين مراحل به اعضاي پروژه دريابند ياري مي‌رساند كه چه كاري را چه موقع و چگونه انجام دهند همچنين اين كار ميان اعضاي گروه نيز هماهنگي به وجود ميآورد. از آن جايي كه منابع موجود و نيازهاي كاربران هر نرم‌افزار با ديگري تفاوت دارد، فرايند توليد نرم‌افزارهاي گوناگون نيز متفاوت است. انجمن IEEE رويه يا فرايند توليد نرم‌افزار را اين گونه تعريف مي‌كند: رويه توليد نرم‌افزار در واقع شامل مراحلي مانند جمع آ‌وري نيازهاي كاربران ، طراحي سيستم با استفاده از تحليل اين نيازها و نوشتن كدهاي نرم‌افزار با استفاده از طرح نرم‌افزار است. همچنين بر اين‌باور است كه از آن جايي كه كيفيت و بهره‌وري نيروي كار با كيفيت روند توليد نرم‌افزار ارتباط مستقيم دارد، طراحي و مديريت رويه توليد نرم‌افزار از اهميت شاياني برخوردار است. براي طراحي يك رويه توليد نرم‌افزار مي توان از روش‌هاي متفاوتي استفاده نمود و از آن جايي كه هر پروژه نرم‌افزاري با ديگر پروژه‌ها متفاوت است، مي‌توان گفت كه رويه توليد آن پروژه نيز با ديگر پروژه‌ها تفاوت دارد. در واقع مي‌توان گفت: انتخاب اين روش‌ها رابطه مستقيمي با اندازه گروه در پروژه دارد و نرم‌افزارهاي بزرگ و كوچك نياز به رويه‌هاي توليد متفاوت دارند در ادامه اين مقاله روش‌هاي توليد نرم‌افزارها، به خصوص نرم‌افزارهاي نسبتاً كوچك كه از گروه‌هاي توليد نرم‌افزاري كوچك‌تري استفاده مي‌كنند، بررسي مي‌شوند و مورد ارزيابي قرار مي‌گيرند روش SCRUM در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌كنند كه تمامي نيازهاي كاربران سيستم را درك كرده‌اند. اما هميشه نيازهاي كاربران سيستم در ابتدا مشخص نيست و كاربران ممكن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است كه برنامه‌نويسان و طراحان سيستم هميشه از آن شكايت مي‌كنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد. اين مدل حاوي مشكلات فراواني است كه به صورت مستقيم به غيرقابل ‌انعطاف‌بودن اين مدل ارتباط دارد. اين مدل مانند يك جاده يك طرفه مي‌باشد كه وقتي اتومبيل در آن حركت مي‌كند، نمي‌تواند مسير خود را تغيير دهد و در جهت ديگري حركت كند. در ابتداي كار كاربر سيستم ممكن است نظراتي در مورد سيستم داشته باشد ولي نمي‌تواند ببيند كه سيستم چگونه كار خواهد كرد و در نتيجه ممكن است وقتي كه سيستم آماده شد، از ساختار و كارايي آن راضي نباشد و تقاضاي تغيير در سيستم را بنمايد. در نتيجه اگر بتوانيم كاربر را از ابتدا در جريان ساخت نرم‌افزار قرار دهيم، ممكن است كه اين مشكل حل شود؛ زيرا مي‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام كار اعلام كنند و در نتيجه از نرم‌افزار تهيه شده راضي باشد. امروزه يكي از روش‌هاي توليد نرم‌افزار كه به خصوص براي پروژه‌هاي نرم‌افزاري كوچك مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش كه روشي به اصطلاح iterative (تكراري يا چرخشي) مي‌باشد، مي‌توان نرم‌افزارهاي كوچك را با كيفيت بالا تهيه نمود. در اين روش كه به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد كه به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند.) شكل1 در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در Scrum هر فاز عملياتي سيستم به Sprint مشهور است. روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يك نقشه مقدماتي و يك معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يك سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند (شكل1). انجام دادن هر Sprint ممكن است از يك تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار كاملي را به‌وجود ميآورند. فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي‌كند. اين Backlog در هر Sprint بروز مي‌شود و هر تكليف براساس اهميتي كه دارد در فهرست تكاليف تعيين اولويت مي‌گردد. هر فرد در گروه يك كار يا تكليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي كه يك Sprint شروع شد، ديگر انجام هيچ تغييري در تكاليف امكان ندارد و حتي درخواست‌كننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت. البته درخواست‌كننده مي‌تواند از قسمتي از نرم‌افزار كه بايد در هر مرحله توليد شود بكاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت كه اين كار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد كه اين نيز به هماهنگي بيشتر گروه كمك خواهد كرد. در اين جلسات كه معمولاً به صورت روزانه است، سه گروه مي‌توانند شركت كنند: گروه تهيه‌كننده نرم‌افزار، مديريت، و درخواست‌كنندگان نرم‌افزار. در طول اين جلسات مسئول جلسه كه اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد: 1- مسئوليت شما (تكاليف) از جلسه قبلي تاكنون چه بوده است و آيا توانسته‌ايد اين تكاليف را به اتمام برسانيد؟ 2- در طول اين دوره به چه مشكلاتي برخورده‌ايد؟ 3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟ مدير Scrum در حقيقت مسئوليت شناسايي تكاليف محوله به اعضا، بررسي روند تكميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي كم كردن ريسك در پروژه را داراست. اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد كه در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي كند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌كند كه آيا مي خواهد به كار روي پروژه ادامه دهد يا انجام پروژه مذكور غيرممكن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد كه در ابتداي پروژه نيازهاي كاربران به صورت دقيق مشخص نباشد و يك گروه كوچك مسئول پروژه نرم افزاري باشد. نتايج تحقيقاتي كه اواخر سال 2005 روي چندين شركت توليدكننده نرم‌افزار در كشور انگلستان انجام دادم، نشان‌دهنده اين بود كه شركت‌هايي كه از Scrum استفاده كرده بودند با حدود چهارصددرصد افزايش در بهره‌وري كار مواجه بودند. البته اين رقم در گروه‌هاي نرم‌افزاري مختلف متفاوت بود و مي‌توان گفت عوامل انساني از جمله مدير پروژه نقش بسيار مهمي در افزايش يا كاهش راندمان پروژه ها دارند. شايد اين سؤال در ذهن شما به وجود آيد كه چرا Scrum ممكن است براي توليد نرم‌افزارهاي كوچك راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي كه در تيم‌هاي كوچك، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد. معايب روش Scram مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشكال نيز دارد. از جمله: 1- Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد. 2- برخي از برنامه‌نويسان حرفه‌اي ممكن است از تكاليفي كه مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه كارشكني كرده و مشكل‌آفريني كنند. 3- از آنجا كه مدير Scrum هم از نظر كيفي و هم كمي بايد پروژه را مديريت كند، Scrum نياز به مديريت بسيار قدرتمند دارد. 4- Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح كوچك) بايد اين روش را با روش‌هاي ديگر ادغام نمود. Scrum را از آن جهت مي‌توان روش خوبي برشمرد كه روشي تحقيقي براساس تخمين، اولويت‌بندي، عملكرد گروه و بررسي نتايج است كه اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت كامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي كوچك را به صورت بسيار محسوسي بالا ببرد. روش XP اشتباه نكنيد! منظور از روش اكس‌پي، ويندوزاكس‌پي نيست. اكس‌پي مخفف Extreme Programming يا برنامه‌نويسي سريع مي‌باشد كه مانند Scrum روشي هوشمند در توليد نرم‌افزار است. در اكس‌پي دو برنامه‌نويس كار را انجام مي‌دهند و قبل از اتمام برنامه آن را چندين‌بار امتحان مي كنند. اكس‌پي در حقيقت روشي از توليد نرم‌افزار است كه براساس آساني، ارتباط، واكنش و تصميم‌گيري سريع استوار است. شكل 2 اصول روش اكس‌پي را نشان مي‌دهد. شكل 2 در روش اكس‌پي اعضاي گروه (كه كاربر سيستم نيز عضوي از آن است) در ابتدا جلسه‌اي تشكيل مي‌دهند و اولويت‌هاي پروژه را مشخص مي‌كنند. اين گروه ممكن است از چند برنامه‌نويس، امتحان‌كننده نرم‌افزار يا Tester و تحليلگر سيستم تشكيل شود كه با هم از ابتدا تا انتهاي پروژه همكاري مي‌كنند. معمولاً در اكس‌پي برنامه‌نويسان در گروه‌هاي دوتايي قرار مي‌گيرند و وظيفه تكميل قسمتي از برنامه را برعهده مي‌گيرند و هر دوي اين برنامه نويسان در مورد هر كدام از نيازهاي كاربران با هم بحث مي كنند و قدم به قدم كلاس هاي برنامه را آماده مي‌كنند. بدين ترتيب كه در ابتدا كلاسي را به صورت ابتدايي و بدون هيچ طراحي اوليه به وجود مي‌آورند و اين كلاس را امتحان مي‌كنند. در صورتي كه اين كلاس فاقد هر گونه اشكال باشد، كد اصلي برنامه را بر آن اساس مي‌نويسند. وقتي يكي از برنامه‌نويسان مشغول نوشتن قسمتي از برنامه است، برنامه‌نويس ديگر وظيفه كنترل صحت اين كدها را عهده‌دار است و در صورت مشاهده هر گونه اشكال، نويسنده كد را مطلع مي‌كند. مانند  Scrum ، در اكس‌پي نيز اعضاي گروه مي‌توانند روند تكميلي توليد نرم‌افزار را مشاهده كنند و در جريان كار قرار گيرند.اكس‌پي روش مناسبي براي مديريت پروژه‌هاي كوچك مي‌باشد كه از دو تا ده برنامه‌نويس تشكيل شده است. اگر چه اصولاً اكس‌پي هيچ رويه خاص و مراحل پيوسته‌اي را مشخص نكرده اما مي توان گفت كه اكس‌پي داري چهار مرحله اصلي مي باشد: الف: مرحله زمانبندي پروژه: در اين مرحله اعضاي گروه با توجه به اندازه نرم‌افزار و كارايي آن برنامه زمانبندي را با هم تنظيم مي كنند. ب: طراحي ابتدايي ج: نوشتن كدهاي برنامه د: امتحان‌كردن كدهاي نوشته شده مطابق تحقيقاتي كه توسط نويسنده انجام شد، مشخص گرديد كه اكس‌پي در پروژه‌هاي بزرگ با تعداد اعضاي بالاي ده نفر اصلاً موفق نخواهد بود و تنها مي‌تواند براي پروژه‌هاي كوچك مفيد باشد. دليل آن را نيز مي توان در طبيعت اين روش دانست؛ زيرا مستندات چنداني براي نرم‌افزار وجود ندارد و فقط دو نفر يا حداكثر چهار نفر مي‌توانند در مورد قسمتي از نرم‌افزار اطلاعاتي داشته باشند. همچنين نرم‌افزار توليدشده توسط اين روش هيچ‌گونه طراحي سازمان يافته‌اي ندارد كه اين موضوع مي‌تواند براي مراحل پس از نصب يعني تعميرات و نگهداري سيستم باعث بروز مشكلاتي گردد. از جمله مزاياي اكس‌پي مي‌توان به اين نكته اشاره نمود كه از آن جايي كه يك برنامه‌نويس به صورت مستقيم كدهاي برنامه را كنترل مي كند، مي‌توان گفت كه كيفيت نرم‌افزار توليدي بالا مي‌رود. همچنين مي‌توان گفت از آن جايي كه دو برنامه‌نويس با هم كار مي‌كنند، آموزش كمتري نياز است و در نتيجه هزينه توليد نرم‌افزار پايين خواهد آمد. اما اين روش مشكلات خاص خود را نيز دارد. مثلاً تصوركنيد اگر در يك گروه، يك برنامه‌نويس تمايلي براي كار با برنامه نويس ديگري را نداشته باشد يا در يك روز يكي از دو عضو گروه غايب باشد يا ... در نتيجه چون نمي‌توان با يك برنامه‌نويس به ادامه كار پرداخت، اتمام پروژه با تأخير مواجه خواهد شد. طبق نتايج تحقيقات به عمل آمده، وقتي يك برنامه‌نويس در كدهاي برنامه به دنبال اشكال مي گردد، حداكثر مي‌تواند ده تا پانزده‌درصد از اشكالات برنامه را پيدا كند. اما وقتي در روشي مثل اكس‌پي دو برنامه‌نويس با هم كار مي كنند و يكي از اين برنامه‌نويسان كدها را كنترل مي‌كند، بيست تا چهل‌درصد از اشكالات ساختاري برنامه خود را نشان مي‌دهد. اما با استفاده از روش‌هاي PSP و TSP كه در ادامه اين مقاله توضيح داده مي‌شوند حتي مي‌توان تا هشتاددرصد اشكالات برنامه (كه رقم بسيار خوبي است) را قبل نهايي‌شدن برنامه شناسايي و رفع كرد. البته برای کسب اطلاعات بیشتر به وبلاگ دوستان مراجعه کنید.www.group5.blogfa.com   روشRational Unified Process) ‌RUP) در اين بخش يكي از معروف‌ترين رويه‌هاي توليد نرم‌افزار كه توسط شركت آي‌بي‌ام طراحي گرديده‌است را معرفي مي‌كنيم. اين روش با نام Rational Unified Process) ‌RUP) در بسياري از پروژه‌هاي نرم‌افزاري به كار گرفته مي‌شود. در حقيقت هدف اصلي RUP مطمئن‌شدن از اين موضوع مهم است كه آيا نرم‌افزار توليدشده نيازهاي كاربرانش را به صورت كامل، با كيفيت بالا‌، در زمان معين و با بودجه مشخص برآورده كرده است يا خير. مطابق تحقيقات انجام شده، از آن جايي كه RUP به تمامي اعضاي تيم، اطلاعاتي مشترك مي‌دهد و تمامي اعضاي گروه با يك زبان مشترك با هم مرتبط هستند، بازده كاري گروه را بالا مي‌برد. RUP داراي سه جزء اصلي است. جزء اول از مجموع راه‌حل‌هاي خوب كه در رويه مي‌تواند مورد استفاده قرار گيرد تشكيل شده است. جزء دوم همان مراحل تهيه نرم‌افزار است و جزء آخر قسمت‌هاي تشكيل‌دهنده اين رويه مي باشد. ‌ ‌ RUP شش راه‌حل خوب كه مي‌تواند در مراحل مختلف اين رويه به ما كمك كند را معرفي كرده است. از آن جمله: 1- استفاده از USE CASEها كه مي‌توانند در جمعآوري نيازهاي كاربران مفيد باشند. 2- استفاده از معماري نرم‌افزار قابل تغيير‌ (‌onent reuse) 3- استفاده از روش‌هاي تكميلي و Iterative براي كنترل بهتر و آسان پروژه نرم‌افزاري‌ 4- استفاده از نمودارهاي UML 5- كنترل تغييرات در نرم‌افزار 6- كنترل كيفيت نرم‌افزار با توجه به درخواست‌هاي اوليه كاربران شكل 3 رويه RUP را نمايش مي‌دهد. همان‌طور كه در اين شكل مشخص شده است چرخه توليد نرم‌افزار به چهار قسمت اصلي تقسيم شده است: الف: Inception phase يا مرحله آغازين: در اين مرحله اهداف پروژه مشخص شده و درخواست‌هاي اوليه كاربران تعريف مي‌شود. از خروجي‌هاي اين مرحله مي‌توان به مدل اوليه Use Case، آزمون ريسك در پروژه و برنامه زمانبندي پروژه اشاره كرد. ب: Elaboration phase يا مرحله مقدماتي: در اين مرحله نيازهاي كاربران تحليل و بررسي شده و راه‌حل كلي طراحي سيستم ترسيم مي‌شود. از خروجي‌هاي اين مرحله مي‌توان از مدل كامل شده Use Case، فهرست نيازهاي كامل كاربران و طرح كلي سيستم نام برد. ج: Construction phase: يا مرحله ساخت و توسعه: در اين مرحله نرم‌افزار طراحي شده ساخته مي‌شود و به اصطلاح، كد برنامه نوشته شده و قسمت‌هاي مرتبط به هم ارتباط داده مي‌شوند. از خروجي اين مرحله مي‌توان از نرم‌افزار، راهنماي استفاده از نرم‌افزار و مستندات سيستم نام برد. د: Transition phase يا مرحله تغييرات: در اين مرحله اگر نرم‌افزار به وجود آمده در مرحله ساخت دچار مشكل شود، مشكل رفع خواهد شد.   شكل 3 همانطور كه در شكل 3 مشاهده مي‌كنيد، تمامي مراحل توسط خطوط عمودي از همديگر جدا شده‌اند و هر مرحله با يك milestone يا نقطه مهم تمام مي‌شود. روش RUP با استفاده از مدل‌هاي مختلف همچنين مشخص مي‌كند چه كسي، چگونه و چه وقت چه كاري را انجام خواهد داد. همان‌طور كه در اين قسمت ذكر شد، روش RUP روشي انعطاف پذير، قابل تغيير و پيشرفته است كه مي‌تواند در صورت استفاده صحيح، باعث افزايش كارايي و كيفيت نرم‌افزار توليدي گردد. اما آيا RUP مي‌تواند رويه خوبي براي توليد نرم‌افزارهاي كوچك باشد؟ در جواب بايد گفت كه RUP را طوري طراحي كرده‌اند كه بتواند براي انواع پروژه‌هاي نرم‌افزاري در هر اندازه مفيد باشد و از آن جايي كه از ابزارهاي خوبي مثل UML نيز استفاده مي‌كند، UML) در گروه‌هاي كوچك كه نرم‌افزارهاي كوچك طراحي مي‌كنند ابزار مدلي خوبي است) مي‌تواند باعث همكاري و هماهنگي بيشتر گروه گردد. اما همان‌طور كه در ادامه اين بحث خواهيد ديد، اگر بتوانيم رويه‌هاي ساده‌تر را با يكديگر ادغام كنيم، شايد بتوانيم راه حلي با كارايي بالاتري داشته باشيم. جهت مطالعه بيشتر در مورد RUP مي‌توانيد به نشاني http://ref.web.cern.ch/ref/CERN/CNL/2002/001/SDTRUP مراجعه كنيد. روش هاي PSP و TSP PSP يا Personal Software Process در حقيقت روش توليد نرم‌افزار نيست بلكه روشي است نوين كه با ملزم نمودن اعضاي گروه پروژه‌هاي نرم‌افزاري به رعايت اصولي مشخص و استفاده از فرم‌ها و تكاليفي مشخص به آن‌ها كمك مي‌كند كارايي و بهره‌وري كاري خود را بالا ببرند. اين روش همچنين حاوي تكنيك‌هاي خوبي براي كنترل، ا‌ندازه‌گيري و تشخيص اشكالات مي‌باشد كه مي‌تواند به شخص (مثلاً برنامه‌نويس) كمك كند تا مثلاً با اندازه‌گيري نرم‌افزار، يادداشت ميزان فعاليت روزانه و ساعات هدر رفته، و اشكالات به وجود آمده، مشكلات را حل كند و در نتيجه بهره‌وري خود را بالاتر ببرد. TSP يا Team Software Process مانند PSP است، ولي براي يك تيم طراحي شده و با طرح روش‌هاي منظم جهت كنترل و جمع‌آوري اطلاعات روزانه به اعضاي تيم كمك مي‌كند تا كارايي خود را بالا ببرند. راه‌حل‌هاي پيشنهادي تا اين قسمت با برخي از روش‌هاي توليد نرم‌افزار آشنا شديم. اگر دقت كنيد تمامي اين روش‌ها و رويه‌ها مي‌توانستند براي توليد نرم‌افزارهاي كوچك مورداستفاده قرار گيرند، اما در ادامه مقاله با چند روش‌ جديد آشنا خواهيد شد كه در چندين گروه نرم‌افزاري كوچك مورد آزمايش قرار گرفته‌اند و در تمامي موارد بازدهي درخور داشته‌اند. در واقع نمي‌توان گفت تمامي روش‌هاي زير روش‌هاي جديدي هستند، بلكه برخي از آن‌ها از ادغام روش‌هاي بالا به وجود آمده‌اند. روش RUP Scrum همان‌طور كه قبلاً اشاره شد، روش Scrum روشي آسان براي توليد نرم‌افزار است كه مديريت پروژه و نظم موجود در آن مي‌تواند بسيار كارگشا باشد. حال تجسم كنيد كه روش RUP را اجرا و قسمت‌هايي از Scrum را در آن ادغام كنيم. پس از اين كار متوجه خواهيد شد كه روش RUP مي‌تواند از مدل Scrum كمك بگيرد و با ادغام اين دو مي‌توان پروسه‌اي منظم براي توليد نرم‌افزارهاي كوچك سازماندهي كرد. اما همان‌طور كه مي‌دانيد نمي‌توان دو رويه ناهمگون را با هم تركيب نمود. آيا RUP و Scrum با هم شباهت‌هايي دارند؟ همان‌طور كه قبلاً بيان شد، هر دو رويه ساخت نرم‌افزار روش حلقه‌اي تكراركننده يا Iterative را خط مشي خود قرار داده‌اند(البته در RUP تعريف بهتر و كامل‌تري از Iterative شده است). در Scrum تعريف نيازهاي كاربران توسط اعضاي تيم انجام مي‌پذيرد، اما در RUP تنها يك شخصRequirement Engineer) يا مهندس مسئول نيازهاي كاربران) است كه اين مسئوليت را برعهده دارد. در زمينه مدل سيستم اگر چه Scrum مسئوليت انجام اين كار را به تمامي اعضاي گروه داده است، اما هر دو روش از مدل UML پشتيباني مي‌كنند و استفاده از آن را پيشنهاد مي‌دهند. ضمناً هر دوي اين روش‌ها روش‌هاي هوشمند و Iterative هستند كه مديريت و اندازه گيري كيفيت نرم‌افزار در تمامي مراحل اين رويه‌ها به خوبي ديده مي‌شود. همچنين هر دوي اين روش‌ها انجام تغييرات را در طول پروژه مجاز مي‌دانند. البته همان‌طور كه در قسمت Scrum توضيح داده شد، اين روش تغييرات را در طول مراحل Sprint مجاز نمي‌داند، اما مدير Scrum مي‌تواند تغييرات درخواستي توسط كاربران را جمعآوري و در جلسه بعدي مطرح نمايد. به تازگي RUP نيز ابزارهاي جديدي مانند RUP Builder و RUP modeller را عرضه كرده كه به مديران پروژه‌ها اجازه مي‌دهد تا برخي از اصول Scrum را درRUP اجرا كنند. در نتيجه اين دو پروسه توليد نرم‌افزار مي‌توانند به كمك بيايند و روشي مناسب براي توليد نرم‌افزارها به‌خصوص در اندازه كوچك باشند. شكل 4 روش RUP XP روش دومي كه مورد آزمايش قرار گرفت، تلفيقي بود از اكس‌پي و RUP. ولي مي‌توان گفت ادغام اين دو رويه بسيار متفاوت است. RUP رويه‌اي بسيار سنگين و اكس‌پي روشي بسيار سبك شكل 4است. مي‌دانيد كه RUP را مي‌توانيم تقريباً براي تمامي نرم‌افزارهاي كوچك و بزرگ به كار برد. اكس‌پي نيز همانند RUP براساس Iterationها يا مراحل پيوسته مانند تحليل، طراحي و امتحان نرم‌افزار استوار است. از آن جايي كه RUP و اكس‌پي از اساس با هم تفاوت‌هاي زيادي دارند و اكثراً تصور مي‌كنند كه RUP راه‌حلي براي توليد نرم‌افزارهاي بزرگ و اكس‌پي براي توليد نرم‌افزارهاي كوچك است، ممكن شما هم تصور كنيد كه استفاده همزمان از هر دوي اين روش‌ها كاردرستي نيست. اما مطابق تحقيقات انجام شده به نظر مي‌رسد كه براي توليد نرم‌افزارهاي كوچك روشي بين RUP و اكس‌پي نياز است.در نتيجه با اضافه‌كردن برخي از تكنيك‌هاي اكس‌پي به RUP مي‌توان به رويه‌اي مناسب‌تردست يافت. قبلاً نيز محققاني روي RUP كار كرده‌اند تا آن را براي پروژه‌هاي كوچك مناسب سازند. مثلاً در سال 2000 يك نسخه از RUP به نام dX معرفي گرديد كه RUP مختصر شده‌اي بود. براي نرم‌افزارهاي كوچك (كه اعضاي پروژه اغلب در يك محيط كار مي‌كنند) اكس‌پي مي‌تواند روشي بسيار خوب باشد، اما اگر اعضاي تيم پراكنده باشند و سيستم بخواهد توسعه يابد، اكس‌پي قادر به جوابگويي نيست و مي‌توان گفت كه با استفاده از قسمت‌هايي از روش قدرتمند RUP مي‌توان به اكس‌پي كمك نمود. براي تلفيق اين دو روش تصوركنيد كه پروژه‌اي شروع شده است. در مرحله Inception يا آغازين مي‌توان از تكنيك‌هاي اكس‌پي در زمينه برنامه‌ريزي زماني و جمع آوري نيازهاي سيستم استفاده نمود. البته نمي‌توان گفت كه هميشه اين دو روش با هم سازگار هستند. مثلاً در اكس‌پي مرحله‌اي به نام طراحي يا Design Phase وجود ندارد. در صورتي كه RUP يك مرحله مجزا براي اين قسمت دارد. روش Iterative Process شايد به نظر برسد كه در پروژه‌هاي كوچك، اعضاي گروه نياز كمتري به ارتباط با يكديگر دارند. اما از آن جايي كه در اين گونه پروژه ها ارتباط بين اعضاي تيم و كاربر نزديك‌تر است و عوامل خارجي نيز نقش مهمي را در پروژه‌ بازي مي‌كنند، در اين پروژه‌ها نياز به ارتباط بين اعضاي تيم محسوس به نظر مي‌رسد. همچنين اگرچه پروژه‌هاي نرم‌افزاري كوچك طبيعتاً نياز به نوشتن كدهاي كمتري دارند و ممكن است به چند مدير نياز نداشته باشند اما مانند پروژه‌هاي بزرگ بايد نرم‌افزاري با كيفيت بالا ارائه دهند. در نتيجه مي‌توان گفت كه روشي براي توليد نرم‌افزار كوچك مناسب‌تر است كه تمامي موارد مذكور را در نظر بگيرد و اجرا كند. رويه Iterative يكي از اين روش‌ها است. با استفاده از اين رويه دو نوع محصول به نام‌هاي Actual و by-product توليد مي‌گردد. در واقع محصولاتي كه در موفقيت پروژه نقش اساسي بازي مي‌كنند، Actulas و آن دسته كه به وجود آمدن Actualsها كمك مي‌كنند را By-Product مي‌گويند (مثلاً طرح اوليه سيستم). در اين مدل هر عضو از گروه مسئول انجام‌دادن قسمتي از كار مي‌شود و اين مدل همان‌طور كه در شكل 5 مشاهده مي‌كنيد، شامل هشت مرحله يا فاز است. شكل 5 اولين مرحله اين رويه جمعآوري اطلاعات از كاربر است. در مرحله بعدي سيستم به صورت جامع تحليل و آناليز مي‌گردد تا اعضاي تيم با مدل كلي سيستم آشنا گردند. سپس در مرحله تحليل، نرم‌افزار به صورت كلي مورد بررسي قرار مي‌گيرد و پس از آن كه مرحله معماري سيستم نام دارد، اجزاي تشكيل‌دهنده سيستم مشخص مي‌شوند و كارايي‌هاي سيستم مشخص مي‌گردند. در مرحله طراحي تمامي اجزاي سيستم طراحي مي‌شوند و در مرحله بعد كدهاي سيستم نوشته مي‌شود. وقتي اين مرحله تمام شد و كدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع‌بندي كدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي‌كنند. در مرحله آخر نيز اعضاي گروه را امتحان مي‌كنند تا اولاً نيازهاي كاربران را تأمين كرده باشد و ثانياً فاقد هرگونه اشكال باشد. اگر نرم‌افزار فاقد اشكال باشد، رويه توليد نرم‌افزار به آخر خواهد رسيد. در غير اين صورت، اعضاي گروه به دنبال منبع مشكل در مراحل قبلي مي‌گردند و مجدداً رويه را از آن جايي كه فكر مي‌كنند باعث بروز اشكال شده است، ادامه مي‌دهند. نتيجه گيري براي دستيابي به موفقيت در پروژه‌هاي نرم‌افزاري، اعضاي گروه بايد از يك رويه يا روش مشخص پيروي كنند. اما براي پروژه هاي كوچك (براي توليد نرم‌افزارهاي كوچك) اين رويه بايد ساده و آسان باشد. اضافه براين، براي دستيابي به موفقيت در پروژه‌ها تنها داشتن يك رويه آسان و كارا كافي نيست بلكه مديران پروژه‌هاي نرم‌افزاري بايد به اين نكته توجه كنند كه اعضاي گروه در موفقيت پروژه‌ها از اهميت شاياني برخوردار هستند و بايد در انتخاب اين افراد حداكثر دقت را مبذول نمود. در ضمن موقع انتخاب يك رويه مناسب بايد اندازه نرم‌افزار را معين نمود و براساس نيازهاي كاربران پروسه توليدي را طراحي كرد. براي تعيين رويه‌اي مناسب در توليد نرم‌افزارهاي كوچك بايد دقت داشت كه اين رويه بايد بسيار ساده باشد تا به اعضاي تيم كمك كند به‌راحتي مراحل تهيه نرم‌افزار را ادامه دهند. از جمله اين رويه‌هاي ساده مي‌توان از Scrum نام برد. Scrum يك تكنيك مديريت پروژه است كه مي‌تواند به تيم‌هاي نرم‌افزاري كوچك كه روي پروژه‌هاي كوچك نرم‌افزاري كار مي‌كنند كمك كند راندمان و كارايي بالاتري در كار داشته باشند. اما اگر اين روش‌ها را با روش‌هاي مناسب ديگر ادغام كنيم، مي‌توانند بيشتر مفيد واقع گردند. پس از Scrum، روش اكس‌پي توضيح داده شد و به عنوان بهترين راه براي توليد نرم‌افزارهاي كوچك از آن نام برده شد. اما اين روش به تنهايي كارايي چنداني نخواهد داشت. سپس RUP كه مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي كوچك ارائه گرديد. اما همان‌طور كه بحث شد، داشتن يك روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلكه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد. منابع: http://xprogramming.com/xpmag/whatisxp.htm www-128.ibm.com/developerworks/rational/library/feb05/krebs www-106.ibm.com/developerworks/rational/library/409.html

http://www.developercenter.ir

پنج توصیه برای تخمین هزینه‌های شروع کسب و کار

پنج توصیه برای تخمین هزینه‌های شروع کسب و کار 

پنج توصیه برای تخمین هزینه‌های شروع کسب و کار
یکی از مشکل‌ترین مسایل کسب و کار، تخمین هزینه شروع آن است. دشواری این مساله از آن روست که هزینه شروع مانند یک هدف متحرک است که به راحتی دست‌کم گرفته می‌شود و تقریبا همیشه دست‌خوش تغییر و تحول است...
تام امرسون (Tom Emerson) رییس مرکز بازرگانی دونالد اچ‌جونز (The Donald H. Jones) دانشگاه کارنگی ملون واقع در پیتسبورگ جمله زیبایی دارد که می‌گوید: "با هیچ شروع کن و نصف آن را به قیمت چندین میلیون دلار بفروش. آن وقت مسیرت را خواهی یافت." فکر می‌کنم زمانی که داشت این جمله را می‌گفت،‌ لبخند عریض و طویلی هم روی صورتش نقش بسته بود.
همه ما می‌دانیم که یک مدل، متاسفانه شاید به غیر از یک لحظه خیلی کوتاه در اوج شیفتگی اینترنتی، تغییر نمی‌کند. مدلی که تغییر و تحول پیدا می‌کند، مستلزم محاسبه و محاسبات دوباره و نیز آگاهی از بعضی از معمول‌ترین اشتباهات ابتدایی است.
در اینجا پنج اصل را که در تخمین هزینه شروع کسب و کار به شما کمک می‌کند، ذکر می‌کنیم:
با یک طرح ثابت شروع کنید و سپس آن را تغییر دهید.
تجربیات گذشته برای شروع کسب و کار، پیروی از یک طرح تجاری (Business Plan) را توصیه می‌کند. شما نیز همین رویه را در پیش بگیرید. اما این به معنی آغاز و پایان تخمین هزینه‌های شروع کار نیست. جف شومان (Jeff Shuman) استاد مدیریت و مدیر مطالعات بازرگانی دانشکده بنتلی (Bentley College) می‌گوید: "معمول بر این است که یک کارآفرین یک فرصت کارآفرینی پیدا می‌کند، یک طرح تجاری جهت سرمایه‌گذاری تهیه می‌کند، میزان سرمایه‌ای که باید تامین شود را تعیین می‌کند، سرمایه‌ را تامین می‌کند و آن را در جهت تامین هدفی که در طرح تجاری‌اش مشخص شده به کار می‌گیرد. "به قول شومان این کار یک مشکل عمده دارد، این طرح در درجه اول منوط به گرفتن جواز کسب و کار است. وی اضافه می‌کند: "در واقع بعضی از فرضیات اولیه شما تقریبا خوب است ولی بعضی دیگر، حتی ارزش کاغذی که برای نوشتن آن‌ها مصرف می‌کنید را ندارند."
شومان و دیگر صاحب‌نظران معتقدند که تخمین هزینه‌ شروع به معنی مرور مکرر فرضیات و تغییر مدل تجاری اولیه شماست. نوشتن یک طرح تجاری، کار مفیدی است. چراکه شما را مجبور می‌کند همه آن‌چه را برای شروع کسب و کارتان نیاز دارید دقیقا بنویسید، مثل کمک حقوقی، کمک مالیاتی، لوازم اداری، تجهیزات، هزینه پست، مکان و فضای کسب و کار، حقوق کارکنان، بیمه و غیره.
اما مدل‌ اولیه‌ای که انتخاب کرده بودید، ممکن است با موارد جدیدی که یاد گرفته و به کار می‌گیرید، دایم تغییر کند.
عجله نکنید و تامل کنید.
اضافه کردن همه چیزهایی که به گمان شما برای یک کسب و کار تمام عیار لازم است وسوسه‌‌انگیز است و در نهایت به این نتیجه می‌رسید که این چیزها همان‌هایی هستند که شما برای شروع به آن نیاز دارید. اما صبر کنید و دنبال مدل کوچک‌تری بگردید. چراکه این کار فرصتی به شما می‌دهد که همه کار را شروع و همه سرمایه‌تان را حفظ کنید. شومان برای توضیح این امر، مثال کسی را مطرح می‌کند که هزینه‌ کل شروع یک کسب و کار خرده‌فروشی در یک مرکز خرید محلی را صدوپنجاه دلار در هر فوت‌مربع تخمین می‌زند. به قول او "شما هم می‌توانید همین‌طور شروع کنید و یک طرح تجاری در همان حد و اندازه بنویسید. اما شاید بهتر باشد برای تخمین میزان تقاضای آن منطقه از محصولات، از یک چرخ‌دستی استفاده کنید."
آزمایشی که به‌عمل می‌آورید، هزینه اولیه شروع را کاهش می‌دهد. نتیجه این‌که در مرحله اول کار،‌ آن‌قدر که به دست‌آوردن اطلاعات اهمیت دارد، سود اهمیت ندارد. به قول شومان: "بدین‌طریق شما می‌توانید به موازات پیشرفت در هر مرحله، بودجه آن را هم تامین کنید. حال وقتی که به مرحله سوم و مرحله توسعه کارتان قدم می‌گذارید، دیگر آمار و ارقامتان براساس تحقیق و گروه‌های شاهد وآزمایشی نیست، بلکه براساس تجزیه عینی و واقعی جاری در دنیاست."
هزینه‌ها را به موقع محاسبه کنید.
محاسبه گردش پول لولیه قسمتی از محاسبه هزینه‌های شروع کسب و کار است. در این مورد، کسب و کارها معمولا خیلی خوش‌بین هستند.
باربارا برد (Barbara Bird)، رییس بخش مدیریت مدرسه بازرگانی دانشگاه آمریکا می‌گوید: "صاحبان مشاغل کوچک ممکن است تولیدات و خدمات خود را زیر قیمت ارایه دهند. آن‌ها با این تصور که برای رقابت باید با قیمت‌های خیلی پایین شروع کنند، دست به چنین اقدامی می‌زنند. ولی لزومی هم ندارد این کار را کنند."
زمان شروع کار را به دقت تخمین بزنید.
وقتی دارید کسب و کاری را شروع می‌کنید، زمان برای شما دقیقا حکم پول را پیدا می‌کند. فرض کنیم می‌خواهید تکلیف اجاره بهای ماهانه مکان کسب و کار را معلوم کنید. اگر آن مکان قبل از شروع کار احتیاج به مرمت داشته باشد، هزینه‌های بررسی شده تا قبل از شروع واقعی کار، حکم هزینه اضافی را دارد. من خیلی از کارآفرینان را دیده‌ام که برای شروع کسب و کارشان یک ترتیب زمانی درنظر می‌گیرند و ابتدا تکلیف و شرایط منطقه‌بندی، امنیت و بازرسی که از طرف آژانس‌های محلی ملزم به مهیا کردن آن هستند،‌ را معلوم می‌کنند.
به‌همین علت، نظر من این است که یک مبتدی آینده‌نگر در امر تجارت و کسب و کار، حتی قبل از رفتن به مراکز مشاوره املاک یا تهیه وام باید به شهرداری و مراکز صدور مجوز برود. پروانه ساخت،‌ معاینه و بازرسی ممکن است زمان افتتاح پیش‌بینی شده را ماه‌ها به تعویق بیندازد. اگر شما به هزینه این زمان اضافی توجه نکنید، نمی‌توانید بلافاصله و درست از سرمایه‌تان استفاده کنید. در مورد ارزش پول واقع‌بین باشید.
بسیاری از صاحبان مشاغل کوچک با استفاده از چک، هزینه شروع کارشان را تهیه می‌کنند. افراد دیگری نیز از دارایی‌های خاصی که در خانه دارند تامین هزینه می‌کنند - که انتخاب این گزینه بسیار جالب، در سال 2003، نرخ بهره را در آمریکا به‌طور بی‌سابقه‌ای کاهش داده است - ولی این روش برای کسب و کارهای بزرگ مناسب نیست. امرسون از کارنگی ملون اظهار می‌دارد که تازه‌کاران باید هنگام تعیین مخارج اولیه و گردش نقدینگی، میزان سرمایه لازم را تعیین کنند. به گفته او: "درصورتی که از پول نقد برای شروع کار استفاده نمی‌کنید، هزینه بهره بدهی‌های خود را نیز باید محاسبه کرده و به مجموع هزینه‌های شروع کار اضافه کنید."

منبع:سايت كار آفرين

استفاده از نوع‌آوري نظام يافته در بسط خواسته‌هاي كيفي

براي بهبود فرآيند طراحي در يك سازمان سه ابزار وجود دارد. اولين ابزار بسط خواسته هاي كيفي( Q FD ) است كه موجب تسهيل طراحي محصول شده، و كليه اطلاعات بدست آمده از مشتري را به زبان مهندسي تبديل مي‌كند. تا پيش از اين تنها دو روش براي دستيابي به نوآوري وجود داشت: ۱-روش گزينش ايده‌اي پاگ 2-روش طوفان ذهني ولي اكنون با افزودن نوع‌آوري نظام يافته( TRIZ ) به QFD بهبودهاي شگرفي در طراحي نوآورانه محصول و فرآيند بوقوع پيوسته است . هدف از اين مقاله بررسي نحوه استفاده از نوع‌آوري نظام يافته در برآورده كردن هرچه بيشتر نيازهاي مشتريان مي باشد . ادبيات موضوع : در سال 400 پس از ميلاد ، گريك پاپوس اصطلاح روش اكتشافي را به عنوان دانش نوآوري و اكتشاف تعريف كرد . آلتشولو با فرآيند نوآوري نظام يافته خود ، جان تازه اي به روش اكتشافي بخشيد . لغت TRIZ سر واژه عبارت روسي نوآوري نظام يافته است كه سر واژه انگليسي معادل آن TIPS مي باشد[1[. آلتشولو پس از تكميل مطالعات خود بر روي اختراعات به نكات زير پي‌برد: چهار سطح براي اختراع و نوآوري وجود دارد . مسائل ابتكاري حداقل يك تناقض را در بر مي گيرند . الگوي استانداردي براي تكميل تدريجي وجود دارد . در بسياري از طرحهاي ابتكاري از اصول مشابهي استفاده مي شود بنابراين مي توان الگوهايي را براي حل مسئله در نظر گرفت [8[. دكتر شيكروميزونو و پرفسور يوجي آكائو ] 1968 [ تكنيك QFD را در ژاپن ابداع نمودند. اين تكنيك اولين بار در 1972 در كارخانه شيپارد شركت ميتسوبيشي مورد استفاده قرار گرفت . در سال 1975 موسسه ژاپني كنترل كيفيت ( JSQC ) كميته تحقيقات رايانه‌اي خود را راه اندازي كرد كه در 1978 ، گروه تحقيقات QFD نام گرفت. به رغم توسعه و افزايش استفاده از اين تكنيك در ژاپن ، توسعه آن در غرب به كندي صورت گرفت و اولين تجربه‌ها در اين زمينه مربوط به شركتهاي فورد و زيراكس در آمريكاست[2[ . تشريح نوع‌آوري نظام يافته : ما معمولاً با دو نوع مسئله روبه رو مي‌شويم ، آنهايي كه داراي راه حلهايي شناخته شده هستند و آنهائي كه داراي راه حل شناخته شده‌اي نيستند . مسائل دسته اول با استفاده از اطلاعات موجود در كتابها ، مجلات فني و يا به كمك متخصصان موضوع حل مي‌شوند . راه‌حلهاي ارائه شده براي مسائل دسته اول از الگوي حل مسئله كه در شكل (شماره 1) نشان داده شده ، پيروي مي‌كنند . در اين روش ، مسئله‌اي خاص با مسئله استاندارد مشابه يا همجنس آن ارزيابي ميشود . مسائل استاندارد داراي راه حلهاي استاندارد و در دسترس هستند كه از طريق آنها مي توان براي ساير مسائل نيز راه حلي پيدا كرد . نوع ديگر مسائل راه حل شناخته شده‌اي ندارند و ممكن است شامل امور متناقضي باشند[3[ . بيشتر تمرينات در نوع‌آوري نظام يافته شامل يادگيري الگوهاي تكراري حل مسئله بوده ، الگوهاي عمومي اين تكنيك براي يك موفقيت خاص كه مخترع با آن مواجه شده بكار برده مي شود[4[. شكل شماره 1 : الگوي عمومي حل مسئله در قرن چهارم دانشمندي مصري به نام پاپ بيان كرد كه دانشي خلاقانه براي حل مسائل ابتكاري وجود دارد. امروزه حل مسائل ابتكاري در حوزه روان شناسي قرار گرفته است و دانشمندان ، ارتباط بين مغز ، آگاهي و ابتكار را بررسي مي كنند . در اين حوزه عموماً راه‌حلهايي از قبيل طوفان ذهني ، سعي و خطا ، الهام و خلاقيت پيشنهاد مي‌شود ، اما در صورت پيچيده بودن مسئله و نيافتن جواب در حوزه دانشي خاص ، تعداد سعي و خطا به شدت افزايش مي‌يابد . مشكل ديگر اين است كه قابليت انتقال ابزار روانشناسي حل مسئله ، مثل تجربه و الهام ، به ساير افراد سازمان وجود ندارد و يا بسيار مشكل است. آلتشولو [1940[ رويكرد بهتري براي حل مسائل ابتكاري مطرح نمود كه بجاي تكيه بر روان‌شناسي به فناوري تكيه مي‌كند و از آن به عنوان نوآوري نظم يافته نام برد [3[. تنها ابزار اين تكنيك، تقويت نوآوري و ايجاد بهبودهاي شگرف در طراحي است . اين ابزار قدرتمند نياز به سازش و ايجاد تعادل ناشي از تضاد بين مقياسهاي مختلف عملكرد را از بين مي‌برد. ضمناً اين تكنيك از شناسائي تضادها به عنوان موقعيتهايي براي بهبود و تصحيح فرآيند طراحي استقبال مي كند[1[. فرآيند قدم به قدم نوع‌آوري نظام يافته بصورت زير است : شناخت مسئله تنظيم كردن مسئله : تنظيم كردن مسئله ، يعني بازنگري مسئله از لحاظ تناقضات فيزيكي به منظور شناخت مسائلي كه ممكن است اتفاق بيفتد .مهمترين سئوالي كه مي بايست در اين قسمت جواب داده شود اين است كه آيا بهبود يك مشخصه فني در حل مسئله مي تواند باعث بدتر شدن وضعيت مشخصه‌هاي فني ديگر شود. جستجو براي حل مسئله اي كه قبلاً خوب حل شده راحلهاي قابل قياس و تطبيق آن با راه حل مسئله به دليل اينكه اين تكنيك بر روي بانك اطلاعاتي كه شامل هزاران اختراع ، اصول ، عملكردها و تناقضات بنا شده ، استفاده از نرم افزارها به مهندسان كمك مي كند تا با حداقل تلاش ، در زمان مناسب به نتيجه مطلوب برسند از جمله نرم افزارهايي كه در مورد اين تكنيك طراحي شده مي توان به نرم افزارهاي TM Innovation work bench (I.W.B)، Improver ، Ideator و Eliminator (Appetizor) اشاره كرد. بسط خواسته ‌هاي كيفي : QFD را مي توان نتيجه منطقي بازار پر رقابت در جهان كنوني دانست . اين تكنيك ، سيستمي انساني بوده و نقطه شروع آن شنيدن صداي مشتري است كه اغلب غير كمي به شمار مي‌آيد . اين سيستم ، صرفاً ابزاري كيفيتي نيست بلكه روشي براي برنامه ريزي تكوين محصولات جديد يا بهبود محصولات كنوني است در يك جمله اين تكنيك را مي‌توان بصورت زير تعريف نمود : QFD فرصتي ايده‌آل براي جدا شدن از فرهنگ (( ما بهتر از همه مي دانيم مشتري چه مي خواهد )) و حركت به سمت فرهنگ (( اجازه دهيد صداي مشتري را بشنويم )) است . QFD در توليد كالا و عرضه خدمات مورد استفاده قرار مي گيرد . اين روش در كاهش هزينه‌هاي توليد ، چرخه طراحي محصول ، دوره زماني تكوين محصول ، هزينه‌هاي مهندسي و راه‌اندازي ، اتلافها ، اعتراضات مشتري و نيز افزايش كيفيت مطابق خواست و سليقه مشتري ، تاثير عميقي مي گذارد [3[. هدف اصلي QFD در واقع تعيين نيازها و احتياجات مشتريان مي باشد . فعل وانفعالات انجام شده بين مشتري و محصول اين احتياجات را مشخص مي كند و براي پي بردن به آن به عملي ترين روش يعني Gemba (زمان و مكاني كه مشتري محصول را مصرف مي كند )پناه مي بريم و با استفاده از نوع‌آوري نظام يافته سعي مي كنيم به ابداعاتي در Gemba بپردازيم [5[ . روشهاي مختلفي براي اجراي QFD وجود دارد كه مي توان به روش اكائو ، ماكابه ، فوكوهارا و پليتز اشاره نمود . با وجود روشهاي متفاوت در اجرا ، منطق و فلسفه همه آنها يكسان بوده و نقطه شروع كار ، طراحي و تكميل ماتريسي به نام خانه كيفيت است .بوسيله اين ماتريس مي توان ميان خواسته‌هاي مشتريان و ويژگيهاي محصول ارتباطي برقرار نمود . از خانه كيفيت در QFD مي توانيم بعنوان يك واسطه براي ماتريس تناقضهاي فني در نوع آوري نظام يافته استفاده نمائيم ، با اين كار مي توانيم پارامترهاي متناقض را شناسائي نمائيم [6[. QFD و نوع آوري نظام يافته: QFD به عنوان ابزاري جهت انعكاس نيازها و خواسته هاي مشتري در محصول بكار مي رود. اگرچه اين تكنيك در درك نيازمنديها مفيد واقع مي شود ولي ابزاري براي حل مشكل نمي باشد ؛ و اين در حالي است كه از نوع‌آوري نظام يافته به عنوان ابزاري جهت يافتن راه حل ابتكاري در مسائل فني جهت توسعه فرآيندهاي محصول استفاده مي شود . نوع‌آوري نظام يافته مدرن براي توليد جوابهاي ابداعي مسائلي كه قبلاً در QFD مطرح شده‌اند روشهاي جديدي پيشنهاد مي دهد؛ كه البته نوشداروي جامعي نمي باشد [7[. خواسته‌هاي مشتريان را مي توان به 3 دسته تقسيم نمود : 1-خواسته‌هاي مورد توقع : خواسته‌هايي بديهي كه حتي اجراي 100% آنها مشتري را راضي نخواهد كرد (مثلاً توقع داريم ماشين راه برود ). 2- خواسته‌هاي آشكار شده : خواسته هايي كه به هر طريقي بيان شده و هر اندازه عملي شوند رضايت مشتري را بيشتر جلب مي نمايد. 3-خواسته هاي هيجان آور : خواسته‌هايي كه مورد انتظار نبوده و درخواست نمي شوند ولي اگر به همراه محصول باشد مشتري خيلي هيجان زده خواهد شد . بر اساس اين طبقه بندي از خواسته هاي مشتري مي توان يكسري سوال از منظر نوع‌آوري نظام يافته ارائه داد كه بايد جواب داده شود. 1-در مورد خواسته هاي طبقه اول از منظر نوع‌آوري نظام يافته بايد بپرسيم : الف- آيا مشتري يك اقدام مورد توقعي را از دست داده كه بايد انجام مي شده ب-آيا مشتري با اقدام مضري برخورد كرده كه نبايد انجام مي شده 2-برخي درخواسته هايي كه معمولاً مشتريها از محصولات انتظار دارند و از سازنده طلب مي نمايند ( مثل افزايش ظرفيت ): از منظر نوع‌آوري نظام يافته بايد بوضوح بفهميم كه آيا مي توانيم يك اقدام سودمند موجود را افزايش دهيم ؟ 3- ويژگيهايي كه دلپذير و خوشايند بوده و دراولين برخورد مشتري را هيجان زده مي‌كنند . از منظر نوع‌آوري نظام يافته بايد به سئوالات زير پاسخ دهيم : الف- آيا مي توانيم اقدام سودمند غير منتظره‌اي را افزايش دهيم ؟ ب- آيا مي توانيم بر يك محدوديت چيره شويم ؟ اگر چه روشي كارا جهت اختلاط اين دو تكنيك تاكنون پيشنهاد نشده است، ولي Yamashiva[2002] و همكارانش با اختلاط سيستماتيك اين دو ابزار روشي جديد بنام فرآيند توسعه محصول ابتكاري ارائه نمودند كه ما را قادر به خلق نوآوري فني كارا در محصول جديد مي نمايد . در اين روش هدف، وظايف، فعاليتهاي محصول، و اجزاء متشكله در چارچوب ساختار سلسه مراتبي گسترش يافته و اجزاء متشكله‌اي كه بيشتر به نوآوري فني نياز دارند ، بوسيله آناليز و تحليل خواسته‌هاي مشتري در قالب محاسبه وزن اجزاء متشكله تشخيص داده مي شوند [9[. نتيجه گيري : با توجه به اين كه نوع‌آوري نظام يافته مي تواند به مهندسان و مبتكران در حل تناقضات فني و فناوريهاي جديد كمك كند ، استفاده از آن در توسعه محصولات جديد حائز اهميت است . نوع‌آوري نظام يافته در تركيب با QFD ، شركتها را قادر به تعيين نيازهاي مهمتر مشتري و سپس حل هرگونه تنگناهاي فني مي‌سازد . نوع‌آوري نظام يافته مي‌تواند به تعيين سطوح جديدي از وظايف و عملكردها براي رسيدن واقعي به سطوح كيفيت مطلوب كمك كند . http://www.iie.ir/index.php?option=com_content&task=view&id=113&Itemid=33

فناوری نمونه سازی سریع

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

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

 

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

مهمترین و کاربردی ترین روشهای نمونه سازی سریع عبارتند از:

Stereolithography (SLA)، Selective Laser Sintering (SLS®)، Laminated Object Manufacturing (LOM™)، Fused Deposition Modeling (FDM)، 3D PRINTING

آرشیتکت و معماری:

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

ماکت سازی:

فناوری نمونه سازی سریع به دلیل ساخت مستقیم از روی مدل طراحی شده در CAD ، امکان ساخت هر مدل و ماکت پیچیده ای را که بتوان آن را در یکی از نرم افزارهای SOLID WORK، CAD ، MECHANICAL DESKTOP و CATIA طراحی نمود را با دقیقترین جزیئات دارا می باشد.

پزشکی:

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

ساخت و تولید و قالب سازی :

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

صنعت جواهر سازی:

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

بازاریابی و کاربردهای تجاری:

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

فرآیند مهم تاثیر گذار در یک سیستم نرم افزاری

در ساخت يک سيستم نرم افزاري سه فرآيند مهم تاثير گذار مي باشند:
- فرآيند توسعه (Development Process): سازماندهی فعالیت ها است برای ساخت یک سیستم
- فرآيند مديريت (Management Process): انتخاب افراد، تجهیزات و فرآیند هاست برای توسعه یک سیستم و کنترل و نظارت بر روند اجرای پروژه (مدیریت پروژه)
- فرآيند پشتيباني (Maintenance Process): کنترل و پشتیبانی نرم افزار پس از تولید آن

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

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

1- ساده ترین روش: تبدیل فرآیند توسعه سیستم در قالب دنباله ای از وظایف مشخص و ترسیم CPM: Critical Path Model ، یک نمودار از تمام فعالیت ها

2- فرایند توسعه خطی Liner: به ترتیب مراحل انتخاب پروژه، تعریف مفهومی (تعریف مساله، امکان سنجی) ، تعریف مشخصات (خواسته ها ، تعریف مساله) ، طراحی (طراحی معماری، تفصیلی) ، توسعه (ساخت سیستم، تست) ، ارزیابی و درنهایت تعریف پروژه جدید

3- مدل آبشاری (Water Fall) : تقسیم وظائف توسعه سیستم در قالب یک مدل آبشاری از تعریف مساله، امکان سنجی، تحلیل (سیستم، خواسته ها)، طراحی ، پیاده سازی و تست ، یکپارچه سازی و تست، نصب و تست ، نگهداری و مرور , با امکان برگشت از یک مرحله به مرحله قبل

4- توسعه مرحله ای، افزایشی و یا نموی Incremental Methods : تقسیم یک مساله به مسائل کوچکتر و انجام هر زیر سیستم (مساله کوچکتر) و انجام هر یک به صورت جداگانه و در صورت امکان اجرا به صورت همزمان

5- الگو سازی (Prototyping) :ایجاد یک الگو برای کاربران برای اینکه درک بهتری از سیستم داشته باشند و درنهایت پیاده سازی سیستم بر اساس این نمونه

6- توسعه سریع سیستم RAD: Rapid Application Development : ادغام برخی مراحل با یکدیگر و استفاده از زبانهای نسل چهارم برای توسعه سیستم (مراحل: برنامه ریزی، طراحی و تست)

7- طراحی تکاملی به صورت حلزونی و یا مارپیچی (Spiral) : توسعه سیستم به صورت افزایشی به صورت بازگشتی Recursive

8- با اضافه کردن مفاهیم برنامه سازی شی گرایی (OOP) به روش حلزونی و تبدیل به صورت موازی بازگشتی (Parallel Recursive Method )

9- توسعه سیستم مبتنی بر مولفه ها (CBSD: Component Based Software Development )

10- توسعه همزمان (Concurrent Development) : توسعه به صورت یک فرآیند سیستماتیک و مرحله بندی و لیبل گذاری هر بخش در هر مرحله. تقسیم سیستم به بخش های مختلف و تقسیم نیروها در بین پروژه های مختلف برای اجرای این بخش ها به صورت همزمان

11- روشهای فرمال : بکارگیری مدل ها و مفاهیم ریاضی در توسعه سیستم

12- روشهای نسل چهارم: بگارگیری از ابزارهای گرافیکی و ابزارهای مهندسی نرم افزار (CASE Tools)

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

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

درآمدي بر مدل‌سازي چابك (Agile Modeling)

  جکیده مطلب

مدل‌سازي چابك (Agile Modeling) رويكرد نسبتا جديدي است به توليد، به خصوص توليد نرم‌افزار. اساس اين رويكرد، چنان چه از نامش پيدا است، چابكي در تحليل، طراحي، ساخت و تست نرم‌افزار و هدف آن توليد نرم‌افزار با كيفيت است. در اين رويكرد، مدل‌سازي و مستندسازي تا اندازه‌اي توصيه مي‌شود كه مورد نياز و مفيد باشد، نه بيش از آن.

 

 اين ديدگاه، توليد مدل‌ها و مستندات را به صرف پيروي از يك متدولوژي يا چارچوب، مضر و اتلاف وقت مي‌داند.

 

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

 

 

 

• پروژه کوچک است (تعداد افراد درگير 2 تا 30 نفر هستند)
• مشتريان و توسع دهندگان نرم افزار در تماس مداوم با يکديگر هستند
• ممکن است نيازمنديهاي در طول اجراي پروژه تغيير کند
• قلمروي پروژه به طور کامل تعريف نشده است
• مسئله پيچيده است

---

 

متدولوژی های توسعه نرم افزار بطور کلی به دو دسته سنگین وزن (HeavyWeight) و سبک وزن (LightWeight) تقسیم می شود .محور اصلی متدلوژی های سنگین وزن مانند RUP شامل برنامه ریزی جامع و مستند سازی از ابتدا تا انتها و طراحی کامل و گسترده می باشد .به عبارت دیگر روشهای سنگین وزن بصورت پیشگو یا Predictive عمل می کنند یعنی در آغاز همه چیز را پیش بینی می کنند در این جا این سوال پیش می آید که آیا همه چیز از ابتدا قابل پیش بینی می باشد؟
مسلما در ابتدای فاز های تحلیل به دلیل تغییر نیاز ها نمی توان همه چیز را پیش بینی کرد بنابراین متدلوژی های سبک وزن بوجود آمدند. این روش ها بیشتر بر روی سادگی و سرعت تمرکز دارند .در این روش ها در یک کار توسعه گروه توسعه فقط روی وظایفی که در ابتدا احتیاج است تمرکز می کنند و آنها را باید سریع تحویل می دهند و در هر مرحله به جمع آوری بازخوردها می پردازند وبه اطلاعات دریافت شده واکنش می دهند

چه چیز یک روش توسعه را تبدیل به agile می کند؟
اگر توسعه نرم افزار به صورت
- افزایشی (incremental) نشر های کوچک نرم افزاری با گردشهای سریع
- مشارکتی (cooperative) کاربر و توسعه دهندگان با یک ارتباط نزدیک به صورت ثابت با یکدیگرکار می کنند
- سر راست (straight forward) خود روش برای یادگیری و تغییر دادن آسان می باشد و خوب مستند شده است
- سازگار (adaptive)قابلیت تغییر پذیری در آخرین لحظات می باشد یعنی انطباق با شرایط
شود متدلوژی به صورت Agile در می آید

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

مدیریت: 
در متدلوژی های سنگین وزن مدیریت بصورت مطلق و استبدادی است در حالیکه مدیریت متدلوژی های سبک وزن بصورت غیر متمرکز و آزاد است که این مدیریت غیر متمرکز باعث تصمیم گیری بهتر برای این روش ها می شود.
نحوه مستند سازی :
یکی از عیب های متدلوژی های سنگین وزن مستند سازیهای سنگین می باشد که کار بسیار دشوار و زمانبری می باشد و باید بصورت جامع و کامل انجام شود (مثلا در Rup باید تمامی مستندات برای هر فاز بطور کامل تهیه شود) در حالیکه در متدلوژی های سبک وزن مستند سازی محدود وبسته به نیاز پروژه انجام می شود.
چرخه های توسعه :
در متدلوژی های سنگین وزن (Cycles) تعداد چرخه ها کم است ولی زمان آنها بسیار زیاد است بنابراین طولانی شدن چرخه ها موجب طولانی شدن زمان انتظار برای رسیدن به نشرها (Release) می شود و این برای کارفرماهای کم طاقت چیز جالبی نمی تواند باشد ! ولی در متدلوژی های سبک وزن چرخه ها بسیار زیاد است اما زمان آنها کوتاه است بنابراین اثر پروژه زودتر مشخص خواهد شد.
معیار موفقیت :
در متدلوژی های سنگین وزن معیار موفقیت در راستای طرح اولیه می باشد که در غیر این صورت پروژه به شکست و تحمل هزینه بر خواهد خورد ولی در متدلوژی های سبک وزن معیار موفقیت بر اساس ارزش کاری (Bussiness Value) مشخص می شود که این باعث انعطاف پذیری این متدلوژی ها می شود .در حالیکه در متدلوژی های سنگین وزن به دلیل همان طرح اولیه این انعطاف پذیری وجود ندارد.
اندازه تیم :
متدلوژی های سنگین وزن احتیاج به یک تیم بزرگ دارند که باید بر اساس تخصص خود در هر کدام از فازها باید عملیات مربوط به خود را انجام دهند که باعث دشوار شدن مدیریت فاز ها خواهد شد.در متدلوژی های سبک وزن اندازه تیم کوچک (حداکثر 30 نفر) می باشد که کوچکی تیم می تواند به بیشتر شدن خلاقیت و همکاری در تیم شود .
بازگشت سرمایه

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

---

سخن آخر

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

---

انواع متدلوژی ها سبک وزن :
XP(Extreme Programming)
Scrum
Crystal Family
FDD(Feature Driven Development)
Dynamic System Development
Adaptive Software Development
Open Source Software Development
سعی خواهم کرد بعدا در مورد هر کدام از این روش ها بیشتر صحبت کنم .