اندکی در مورد مدیریت پروژه - قسمت اول

مطلب پایین در مورد مدیریت پروژه است که این حقیر نوشته ام .

مدیریت در این سطح ها انجام خواهد شد :
* Project Scope Management
Project Time Management *
Project Cost Management *
Project Quality Management *
Project Human Resource Management *
Project Risk Management *
Project Integration Management*

توضیح مختصر و در حد معلومات خودم در مورد Term های بالا , Scope یعنی مشخص کردن محدوده سیستم , که این محدوده رابطه مستقیمی با Time و Cost داره که این سه تا با هم یک مثلث آهنی رو تشکیل میدهند , چنانکه اگر دامنه پروژه بزرگ بشه پس زمان و هزینه بیشتری در پی خواهد داشت .

و اونای دیگه هم که معلومند .

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

Planning: طرح ریزی و تصمیم گیری اینکه این پروژه چگونه کامل خواهد شد .

Executing : بعد از طرح ریزی , تیم کاری مشغول به کار خواهند شد .

Controlling: تیم کاری توسط مدیر (ها) کنترل می شوند .

Closing : همان بهشت برین .

البته بین مراحل Planning و Controlling و Executing ممکن است Iteration باشد .

هر یک از مراحل رو می توان به صورت جداگانه در نظر گرفت, یعنی : PDCA : Plan-Do-Check-Act

PLAN: برای یک بخش طرح ریزی انجام می دهید . این همون بخش planning بود که قبلا اشاره شد .

Do : طرح تون رو پیاده سازی می کنید . این همون Executing بود که قبلا اشاره شد .

Check : اینم مثل همون بخش کنترل است که گفته شد .

Act : ممکن است بخواهید بهبودی در روند اجرای این پروسه بدهید , به عبارت دیگر این مرحله , مرحله بازنگری است . و برگشت به نقطه Plan دوباره .

موفق باشید

سخنانی از بزرگان

اشکال زدایی (debug) یک کد چندین مرتبه از نوشتن آن سخت‌تر است. بنابراین اگر کد اولیه خود را بسیار هوشمندانه بنویسید، جهت اشکال زدایی آن به اندازه‌ی کافی باهوش نخواهید بود! (Brian Kernighan)

تنها دو نوع زبان برنامه نویسی وجود دارد: آنهایی که برنامه نویس‌ها از آن شکایت دارند و آن‌هایی که اصلا مورد استفاده قرار نمی‌گیرند! (Bjarne Stroustrup)

هر کسی می‌تواند کدی بنویسد که یک کامپیوتر آن‌را درک کند. یک برنامه نویس خوب کدی را می‌نویسد که برای سایر همکارانش قابل درک باشد. (Martin Fowler)

اندازه‌گیری درصد پیشرفت یک پروژه برنامه نویسی با شمارش تعداد سطرهای کدهای آن همانند اندازه گیری درصد پیشرفت ساخت یک هواپیما از طریق وزن کردن آن است! (Bill Gates)

برنامه نویسی سطح پایین (Low-level) روح برنامه نویس‌ها را جلا می‌بخشد! (John Carmack, ID software)

بزرگی واقعی با اندازه گیری مقدار آزادی که به دیگران عطا می‌کنید، سنجیده می‌شود و نه به اینکه چگونه دیگران را وادار می‌کنید تا آنچه را که مد نظر شما است اجرا کنند. (Larry Wall)

هیچگاه از gets و sprintf استفاده نکنید، در غیر اینصورت شیاطین به زودی به سراغ شما خواهند آمد! (FreeBSD Secure Programming Guidelines)

صحبت کردن ساده است. کدت رو نشون بده! (Linus Torvalds)

علوم رایانه هیچگاه شخصی را تبدیل به یک برنامه نویس خوب نمی‌کنند همانطور که مطالعه در مورد رنگ‌ها و قلم‌ها شما را تبدیل به یک نقاش خوب نمی‌کند. (Eric Raymond)

هیچ برنامه‌ای تا زمانیکه آخرین یوزر آن بمیرد به پایان نخواهد رسید! (از یک گروه پشتیبانی نرم افزار ناشناس!)

برنامه نویس‌های C هرگز نخواهند مرد. آن‌ها فقط تبدیل به void خواهند شد. (ناشناس)

پایان دنیای یونیکس 2 به توان 32 ثانیه پس از اول ژانویه 1970 است! (ناشناس)

زمانی‌ که کد می‌نویسید فرض کنید شخصی که قرار است در آینده از کدهای شما نگهداری کند یک دیوانه‌ی زنجیری است که آدرس خانه‌ی شما را می‌داند! (Rick Osborne)

سادگی یک برنامه یکی از شرایط قابل اطمینان بودن آن است. (Edsger Dijkstra)

یونیکس سیستم عامل ساده‌ای است، اما شما باید فرد باهوشی باشید تا بتوانید این سادگی را درک کنید! (Dennis Ritchie)

اگر به کامپایلر دروغ بگوئید او بعدا انتقام خواهد گرفت! (Henry Spencere)

پرل تنها زبان برنامه نویسی است که پیش و پس از رمزنگاری RSA به یک شکل به نظر می‌رسد! (Keith Bostic)

تنها دو صنعت هستند که به مصرف کنندگان خود "کاربر" می‌گویند: صنعت کامپیوتر و تجارت مواد مخدر! (ناشناس)

نقل شده از بلاگ:  وحید نصیری

چرا نرم‌افزارها می‌میرند؟

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

اشاره : معمولاً وقتی سازمان یا شرکتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فکر نمی‌کند که ممکن است قبل از تحویل گرفتن آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده کند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فکر نمی‌کند که این نرم‌افزار روزی می‌میرد.
معمولاً وقتی سازمان یا شرکتی نرم‌افزاری را سفارش می‌دهد، هیچ‌گاه به این موضوع فکر نمی‌کند که ممکن است قبل از تحویل گرفتن  آن، نرم‌افزار او بمیرد و از آن محصول نتواند استفاده کند. یا اگر نرم‌افزار را سالم تحویل بگیرد باز هم به این موضوع فکر نمی‌کند که این نرم‌افزار روزی می‌میرد. سازمان‌های بزرگ هزینه‌های قابل‌توجهی را صرف خرید تجهیزات IT از سخت‌افزار گرفته تا نرم‌افزار و تجهیزات شبکه‌ای می‌کنند و نکته قابل توجه این‌که بیشترین درصد خرابی و مشکلات از آن نرم‌افزار است، اما به راستی چرا این‌گونه است؟ چرا در اکثر پروژه‌های نرم‌افزاری کشورمان این مشکل دیده می‌شود؟ تجربه شخصی من برای پاسخ دادن به این سؤالا‌ت، عدم توجه به هشت نکته مهم را دخیل می‌داند:  1- یکی از مشکلات پروژه‌های نرم‌افزاری نداشتن برنامه کاری یا داشتن برنامه زمان‌بندی غیرحقیقی است. به عنوان مثال، در حالی که نظر کارشناسی این است که مدت زمان اتمام پروژه با توجه به اجزای آن چهار ماه طول خواهد کشید، شما به عنوان مدیر پروژه نرم‌افزاری نباید قول بدهید که پروژه دو ماه دیگر به اتمام می‌رسد. این کار باعث خواهد شد به دلیل کمبود وقت کیفیت نرم‌افزار کم شود.  2- به‌کارگیری نرم‌افزاری که کیفیت پایینی داشته باشد حتماً با شکست روبه‌رو می‌شود. تصور کنید که روی اجزای سیستم‌های نرم‌افزاری آزمایش کاملی صورت نگیرد و از روش‌های آزمایش مکرر در هنگام برنامه‌نویسی استفاده نشود. اگر نیازهای کاربران (نه به صورت کامل بلکه جزئی) تغییر کند سیستم دیگر نمی‌تواند قابل استفاده باشد.  3- نباید فکر کنیم اتفاق خارق‌العاده‌ای رخ می‌دهد و کاربران سیستم همان‌گونه که ما به آن‌ها می‌گوییم، با سیستم رفتار می‌کنند. شاید ورود اطلاعات زیاد و رفتارهای مختلف کاربران در سیستم تأثیر داشته باشد و باعث شود نتیجه خوبی از پروژه نگیریم.  4- اگر چه تغییر کلی نیازهای کاربران پروژه نرم‌افزاری را با مشکل روبه‌رو می‌کند، اما باور کنید که کاربران نیازهای جدیدی خواهند داشت. بهتر است در پروژه‌های نرم‌افزاری از روش‌های آبشاری قدیمی استفاده نکنیم و از روش‌های نوین مانند test driven development بهره بگیریم. (برای اطلاعات بیشتر به این نشانی مراجعه کنید)  5- در پروژه‌های نرم‌افزاری از نیروهای آزموده و حرفه‌ای استفاده کنیم. اگر چه نیروهای غیرحرفه‌ای می‌توانند برنامه‌های کوچکی تولید کنند، اما پروژه‌های نرم‌افزاری بزرگ هم به تخصص و تجربه زیادی نیاز دارند. به صرف این‌که فردی تنها تحصیلات دانشگاهی عالی در رشته نرم‌افزار دارد نمی‌توان گفت که می‌تواند عضوی از تیم پروژه باشد. در انتخاب نیروهای پروژه دقت کنید، چون دلیل از بین رفتن اغلب پروژه‌های نرم‌افزاری استفاده از نیروهای غیرمتخصص است.  6- برخی از کاربران سیستم که خود به استفاده از سیستم راغب نبودند و سرپرستشان آن‌ها را مجبور می‌کرد از سیستم استفاده کنند، در مقابل سیستم و نرم‌افزار مقاومت می‌کردند و می‌خواستند همچنان به صورت دفتری کار خود را انجام دهند، زیرا به نظر آن‌ها استفاده از سیستم‌های نرم‌افزاری حیطه وظایف آن‌ها را محدود می‌کند و نمی‌گذارد آن‌ها در انجام وظایف کوتاهی کنند (یا به عبارتی از زیر کار در بروند). شاید هم هنوز به نرم‌افزارها اعتماد ندارند و بر این گمانند که مغزشان در امور محاسباتی از کامپیوتر بهتر کار می‌کند.  7- کاربران اصلی سیستم در طول مراحل طراحی نرم‌افزارها حضور ندارند، به همین دلیل است که وقتی نرم‌افزار آماده می‌شود می‌خواهند آن را تغییر دهند. کار آن‌ها مانند این موضوع است که تنها اندازه‌های خود را به خیاط بدهیم و بگوییم حوصله پرو را نداریم. حاصل کار شاید لباسی باشد که اندازهِ شما باشد، اما به احتمال خیلی زیاد کارایی کافی را نخواهد داشت.  8- فرض کنید نرم‌افزار عاری از اشکال است و در اختیار کاربر قرار می‌گیرد. حال اگر کاربر به دلیلی وقت خود را صرف ایرادگیری از سیستم کند یا اطلا‌عات مورد نیاز را به آن وارد نکند پروژه نرم‌افزاری به نتیجه نخواهد رسید. برخی از کاربران سیستم فکر می‌کنند که وظیفه برنامه‌نویس وارد کردن اطلاعات به سیستم است. در کشورهای صنعتی درصد مشکلات پروژه‌های نرم‌افزاری بسیار کمتر از کشور ما است. تجربه به ما نشان داده که تقریباً بیست‌درصد از پروژه‌های نرم‌افزاری کوچک و حدود ده تا پانزده درصد از پروژه‌های نرم‌افزاری بزرگ مشکل دارند. در واقع این پروژه‌ها آنقدر مشکل دارند که نمی‌توان آن‌ها را اصلاح کرد. جالب‌تر این‌که برخی از مدیران پروژه‌های نرم‌افزاری که پروژه‌‌هایشان با مشکل روبه‌رو می‌شود، نمی‌خواهند این واقعیت را بپذیرند که نرم‌افزارشان مرده است و دیگر نمی‌توان کاری برایش انجام داد. به عنوان مثال، حدود دو سال پیش در یکی از سازمان‌های دولتی به وسیلهِ گروهی که تخصص نرم‌افزاری نداشته و تنها فنی بودند سیستمی طراحی شد و تیم نرم‌افزاری مسئولیت اجرای آن را به عهده گرفت. بعد از آماده سازی محصول کاربر سیستم تغییرات زیادی در سیستم به وجود آورد که ساختار کلی آن را تغییر داد و هنوز بعد از این همه مدت هیچ‌گاه سیستم عملیاتی نشده است. نمی‌توانیم تمامی اشکالات را به کاربر یا مدیر پروژه نسبت بدهیم. به نظر من اگر بتوانیم تمامی هشت نکته‌ای را که در بالا اشاره شد، در نظر بگیریم، درصد کمتری از پروژه‌های نرم‌افزاری ما با شکست روبه‌رو می‌شوند.