تکنیکهای مدیریتی برای برنامه ریزی، سازماندهی، نظارت و کنترل پروژه های نرم افزاری 1

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

 

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

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

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

 

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

چه کسی انجامش میدهد؟ همه به نوعی مدیریت می کنند. ولی محدوده این مدیریت بستگی به نقش و فرد مدیر دارد. یک مهندس نرم افزار اعمال و وظایف روزانه خود را مدیریت، نظارت و کنترل میکند. مدیران پروژه وظیفه مدیریت، نظارت و کنترل مهندسین نرم افزار را به عهده دارند. مدیران ارشد روابط کسب و کار میان بازار و نرم افزار را تنظیم می کنند.
چرا اینقدر مهم است؟ ساخت نرم افزار کاری بس پیچیده است، بخصوص اگر افراد زیادی را شامل شود و زمان زیادی طول بکشد. برای همین است که ساخت نرم افزار و فرایند تولید آن باید مدیریت شود.
چه قدم هایی دارد؟ درک 4p (People, Product, Process, Project). افراد باید سازماندهی شوند تا کار نرم افزار را بخوبی انجام دهند. ارتباط با مشتری باید رخ دهد تا گستره نرم افزار و نیازها درک شوند. فرایندی مناسب برای افراد و محصول باید انتخاب شود. پروژه باید به خوبی زمانبندی شده و وظایف طبق برنامه زمانبندی شده انجام شوند: تعریف محصولات کاری، برقراری نقاطی برای سنجش کیفیت و برقراری مکانیزمهایی برای نظارت و کنترل کار طبق زمانبندی.
محصول کاری چیست؟ یک پروژه براساس یکسری فعالیتهای مدیریتی آغاز میشود. برنامه فرایند شامل وظایفی که باید انجام شوند، افرادی که دخیل هستند و مکانیزمهایی برای سنجش ریسک، کنترل تغییرات و ارزیابی کیفی می باشد.
چگونه مطمئن شوم آنرا بدرستی انجام داده ام؟ هیچ وقت کاملا مطمئن نخواهید شد که یک برنامه صحیح است مگر اینکه یک محصول با کیفیت را به موقع و با بودجه مناسب تحویل داده باشید. با این وجود یک مدیر نرم افزار این کار را به درستی با تشویق تیم برای کار گروهی و تمرکز بر کار، وظایف تیمی و انفرادی و نیازهای مشتری و سنجش کیفیت انجام میدهد.

4P

یک مدیر پروژه موفق خود را روی 4P (افراد – People، محصول – Product، فرایند – Process، پروژه – Project) متمرکز میکند. ترتیب اختیاری نیست. مدیر نرم افزاری که فکر میکند فرایند تولید تنها بسته به کوشش و سخت کوشی افراد دارد هیچگاه به موفقیت نخواهد رسید. مدیری که نتواند در ابتدا درک عمیقی از نیازهای مشتری پیداکند، مطمئنا راه حل درستی را برای مسئله ای اشتباه برنامه ریزی خواهد کرد. مدیری که بدون تهیه یک برنامه محکم و مطمئن شروع کند، موفقیت پروژه را به شدت در معرض خطر قرار خواهد داد.

 

 

افراد

بحث تولید (کشت) افراد مجرب در زمینه تولید نرم افزار از سال 1960 شکل گرفت. در واقع فاکتور People در بحث تولید نرم افزار بسیار مهم بوده و Software Engineering Institute مدلی را در همین زمینه با نام PM-CMM ارائه داده است: برای ارتقاء آمادگی موسسات تولید نرم افزار برای ایجاد محصولات بسیار پیچیده نرم افزاری با کمک در تولید، جذب و رشد استعدادهای انسانی.
از طرف دیگر مدل بلوغ نیرو حوزه های زیر را برای افراد درگیر تولید نرم افزار شامل میشود: استخدام، انتخاب، مدیریت کارایی، آموزش، پاداش، ارتقاء شغلی، سازماندهی و طراحی شغل و تیم و توسعه فرهنگی. موسساتی که با استفاده از این مدل به نیروی انسانی بالغی دست یابند، با احتمال بیشتری میتوانند از پس تولید محصولات پیشرفته بر بیایند.
مدل PM-CMM همراه با مدل بلوغ نیرو می تواند کمک بسیاری در ارتقاء شرکت ها در زمینه تولید محصولات بالغ کند.
مسائل مرتبط با مدیریت افراد و ساختار پروژه های نرم افزاری در ادامه در همین فصل بحث خواهد شد.

 محصول

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

فرایند

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

پروژه

ما تنها به یک دلیل پروژه های نرم افزاری برنامه ریزی شده و کنترل شده را هدایت می کنیم – این تنها راه شناخته شده مدیریت پیچیدگی است. و تا کنون همچنان در حال مبارزه هستیم. در سال 1998 داده های صنعتی بیان کرد 26% از پروژه های نرم افزاری درجا شکست خورده و 46% از آنها کمبود بودجه و زمان (خروج از زمانبندی) را تجربه کرده اند [REE99]. اگرچه نرخ موفقیت پروژه های نرم افزاری در حال بهتر شدن است همچنان نرخ شکست بیشتر از آن چیزی است که باید باشد.
برای جلوگیری از شکست پروژه مدیر پروژه و مهندس نرم افزار که محصول را می سازد باید از یکسری هشدارها اجتناب کنند، فاکتورهای موفقیت که آنها را به سوی مدیریت صحیح پروژه میبرد را بشناسند و با عقل سلیم دست به برنامه ریزی، نظارت و کنترل پروژه زنند. هرکدام از این مباحث در قسمت 3.5 و فصل های آتی بحث می شوند.

 

 

بازدید: 1886

نظرات

ارسال پاسخ