دنیای مجازی
فناوری اطلاعات +جهان=جهان بی میهن
درباره وبلاگ


دین و دنیایت را نزد خداوند به امانت گذار،و از او بهترین مقدرات را هم‏اکنون و در آینده،در دنیا و آخرت مسئلت نما!
آخرین مطالب
عضویت درخبر نامه
Check PageRank


دنیای مجازی
on Google+

صد فیلم برتر شاهکار سینما صد فیلم برتر شاهکار سینما
از هنرمندان بزرگی چون:آلپاچینو
آلن دولن ، مارلون براندو ،‌ آنتونی کوئین
مجموعه آثار دکتر علی شریع
تمام آثار دکتر شریعتی شامل کتاب، فیلم ویدئویی و سخنرانی
X
تبلیغات در بلاگ اسکای
سه شنبه 8 آذر ماه سال 1390 :: 09:35 AM ::  نویسنده : محمدرضا گرامی
او فکر می‌کرد که می‌توانم طبق این زمان‌بندی پروژه را به پایان برسانم. من برنامه‌زمان‌بندی را به جزئیات بیشتری تقسیم کردم. زمان‌بندی کلی پروژه را نیز برای هر کار مورد نیاز در پروژه، به واحدهای کوچک‌تر تقسیم کردم سپس اعضای تیم را بر سر کارها گماردم. روزها را با فروکردن سرم داخل مانیتور کامپیوتر و مشغول‌شدن به بسط و توسعه‌برنامه‌زمانبندی به آخر می‌رساندم.
 
دست آخر طرح پروژه‌ای بسیار مفصل در دست داشتم که هیچ منطق مشخصی نداشت و از آدم‌ها می‌خواست تا کارهای چهل‌ساعته را ظرف یک ربع به پایان برسانند یا از برخی دیگر می‌خواست تا برای به پایان رساندن کارشان، هفته‌ای 200 ساعت کار کنند؛ اما به طور غریبی برنامه‌ریزی‌ام، با چارچوب زمانی مورد نظر مدیر جفت و جور شد. با این حال خودتان متوجه مشکل شده‌اید.


ادامه مطلب ...
دوشنبه 9 اردیبهشت ماه سال 1387 :: 07:52 AM ::  نویسنده : محمدرضا گرامی

علی قادری*
ghaderi.ali@gmail.com
تحقیقات اخیر نشان داده است که حدود 62 درصد پروژه‌های IT در زمان تعیین شده و یا با هزینه پیش‌بینی شده نتوانسته‌اند به انجام برسند.
در واقع بسیاری از پروژه‌های IT قبل از اتمام، لغو شده و یا اصلاً پیاده‌سازی نشده‌اند.

طبق آمار ماه آگوست 2007 ، از این میان، 49 درصد پروژه‌ها دچار مشکل افزایش بودجه لازم، 47 درصد دچار مشکل هزینه‌های نگهداری پیش‌بینی نشده و 41 درصد دچار مشکل عدم جوابگویی نیازها شده‌اند.
دلیل عمده شکست این پروژه‌ها مربوط به مدیریت پروژه (Project Management) می‌باشد.

به طور کلی پروژه‌های IT بر اساس موفقیت به سه طبقه کلی تقسیم می‌شوند:
• Successful Projects : پروژه‌هایی که به موقع و با هزینه تعیین شده و نیز با کلیه ویژگی‌های تعریف شده به پایان رسیده‌اند.
• Failed Projects : پروژه‌هایی که لغو شده و یا به مرحله پیاده‌سازی نرسیده‌اند.
• Challenged Projects : پروژه‌هایی که با هزینه و یا زمان بیشتر و یا قابلیت‌های کمتری،انجام و به بهره‌برداری رسیده‌اند.

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

به طور کلی دلایل اصلی شکست پروژه‌های IT عبارتند از :
1)-Poor Planning (طرح ریزی ضعیف)
2)-Unclear Goals and Objectives (اهداف و مقاصد غیرشفاف و نامشخص)
3)- Objective Changes during Projects (تغییرات اهداف پروژه در حین انجام آن)
4)-Unrealistic Time or Resource Estimate (پیش‌بینی غیرواقعی زمان و یا منابع پروژه)
5)- Lack of Executive Support and User Involvement (نقصان پشتیبانی اجرایی و درگیر نمودن کاربران در پروژه )
6)- Failure to Communicate and Act as a Team (شکست در ایجاد ارتباط مدیر پروژه با تیم پروژه)
7)- Inappropriate Skills (تجربه‌های ناکافی و غیرمقتضی تیم پروژه)
8)- Lack of Testing and QA(Quality Assurance) standards(نقصان استانداردهای تست و تضمین کیفیت)
9)- Users and Organizations Resistances (مقاومت‌های کاربران و سازمان‌ها در پذیرش سیستم‌های جدید)

نتیجه‌گیری:
مدیران پروژه می‌توانند با رعایت توصیه‌های زیر احتمال شکست پروژه‌ها را کاهش دهند:
• توجه به موارد بحرانی موجود در پروژه و نیز مدیریت تغییرات (Changes Management)
• انجام فرآیندهای لازم جهت برخورد با ریسک‌های موجود در پروژه
• مشخص ساختن اهداف پروژه به صورت شفاف
• عدم استفاده از تخمین خطی در پیش‌بینی زمان و منابع پروژه
• پشتیبانی گرفتن از مدیریت اجرایی پروژه و ارتباط مستمر با تیم پروژه
• کسب اطمینان از وجود تجارب طرح‌ریزی و استفاده از تکنولوژی‌های و راه حل‌های مناسب
• ایجاد پروسه تست و تضمین کیفیت پروژه‌ها(Projects Quality Assurance)

*مدرس دانشگاه

منبع:ایتنا

جمعه 26 بهمن ماه سال 1386 :: 07:36 AM ::  نویسنده : محمدرضا گرامی

نویسنده : www.computerworld.com
مترجم : یاسمن حریری

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

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

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

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

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

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

از آن جایی که انتظار دارم گونه‌های متعددی از تست بر روی پروژه‌ها صورت گیرد، نمی‌توانم تنها از "تکمیل تست" به عنوان مرحله‌ای مهم نام ببرم. به عنوان مثال، زمانی که می‌گویم «کارکرد یک» تکمیل شد، فهرستی به شرح زیر ارایه می‌دهم:

  • کد «کارکرد یک» بدون اخطار بر روی تمامی پلاتفرم‌ها کامپایل می‌شود.
  • تست‌های واحد «کارکرد یک» مورد بررسی قرار گرفته و اجرا می‌شوند.
  • Smoke Test تستی که به سرعت و برای مرور دوباره‌ی سیستم و آگاهی از نقاط ضعف آن صورت می‌گیرد) «کارکرد یک» انجام شد«.
  • کارکرد یک» مورد آزمون قرار گرفته و تعریف شد. تست با موفقیت صورت گرفت.

از فهرست بالا مشاهده می‌شود که من و تیم پروژه، نمی‌گوییم «کارکرد یک» تکمیل شد، مگر آن که تمامی کدها مورد آزمایش قرار گرفته و به درستی و بدون هیچ کم و کاستی اجرا شوند.

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

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

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

منبع :www.systemgroup.net

جمعه 15 تیر ماه سال 1386 :: 10:56 AM ::  نویسنده : محمدرضا گرامی

پروژه چیست؟

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

-    هر قسمت از کاری که در سازمان انجام می گیرد را یمتوان یک پروژه دانست به شرطی که مشخصات زیر را داشته باشد: 1- افق زمانی مشخص

    2- مجموع خوب و تعریف شده و واضح از ستاده ها

    3- مجموعه ای از منابع

    4- دلیلی برای وجود آن کار

    5- ساختار سازمانی که نشان دهنده نقش ها و مسئولیت های خاص است.

      - پروژه مسئله ای است که د رجریان حل قرار گرفته باشد.

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

 

انواع پروژه:

1-      پروژه مطالعاتی

2-      پروژه خدماتی

3-      پروژه اجرایی

 

ارکان پروژه

کارفرما: کارفرما در حقیقت مالکو صاحب اصلی پروژه محسوب می شود.

مشاور: مشاور بازوی فنی کارفرما است.

پیمانکار: اجراکننده پروژه می باشد.

 

مزایده: عملی برای فروش عمده کالا ی مورد نظر به بالاترین قیمت ممکن می باشد.

مناقصه: عملی برای انتخاب پیمانکار یا خرید خدمات با پایین ترین قیمت ممکن است.

 

مراحل انجام پروژه:

1-      مطالعات مرحله یکم- مطالعات توجیهی

2-      مطالعات مرحله دوم- طرح تفضیلی

3-      اجرا

 

پنجشنبه 10 خرداد ماه سال 1386 :: 00:42 AM ::  نویسنده : محمدرضا گرامی
مدیریت خلاق برای موفقیت پروژه





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

خلاقیت می تواند مدیریت شود آن می تواند تمرکز گرا باشد و آن می تواند دلیلی برای موفقیت پروژه ها باشد. TRIZ یک روش برای حل مساله است که توانایی تیم پروژه در حل ریسکهای ایجاد شد در مساله را تسریع می کنند .(Tate and Domb 1997). TRZ مخفف روسی تئوری حل خلاقانه مساله است. این روش توسط آلتشولر و هم دانشگاهی هایش توسعه داده شده است. آن اکنون یک علم بین المللی خلاقیت است که به الگوهای مسایل و راه حل ها متکی است.
بیش از 8/2 میلیون الگو تجزیه و تحلیل گشته تا الگوههای مربوط به راه حل های مسایل فنی استخراج گردند.
تحقیقات TRIZ با بیان این فرضیه آغاز می شود که یکسری اصول جهان مشمول اختراع وجود دارد که مبنایی برای نوآوری خلاق با استفاده از تکنولوژی های پیشرفته می باشد . این بدین معنی است که اگر این اصول تعریف و شناسایی گردند می توانند به تفکر افراد در ایجاد فرآیندهای مبتنی بر نوآوری به صورت قابل پیشبینانه تری عمل نمایند . این تحقیق در طی چندین مرحله در طول 50 سال گذشته تکامل یافته است , سه یافته اصلی از این تحقیق در زیر ارائه می شود:

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

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

شکل 1 این فرآیند را به صورت گرافیکی توصیف می کند:


شکل (1) : روش حل مساله با استفاده از TRIZ

نوآوران مساله خود را با مسایل عمومی TRIZ مطابقت می دهند, سپس راه حلهای عمومی TRIZ برای حل آن مساله را با راه حلی که خود پیشنهاد می دهند مقایسه می نمایند. با این روش , TRIZ آزمایشهای لازم را کاهش می دهد و موثرترین راه حل برای مساله مورد نظر را که مستقل از صنعتی خاص است , ارائه می کند.
برای مثال دلیل قاطع این روش از صنعت دارو سازی استخراج شده است(Anderson 1997 )

مطابق جریان شکل 1 , مساله ویژه به شرح زیر می باشد:

باکتری تیلور برای انتشار هورمونهای انسانی استفاده می شود , تولید یک محصول برتر که آن از منابع حیوانی تصفیه و استخراج می گردد. تولید نمودن محصول , مقادیر خیلی زیاد سلولهای باکتری تیلور که پرورش داده می شوند, سپس سلولها باید شکسته شوندو مواد دیواره سلول از بین رود, بطوریکه هورمونهای مفید بتوانند فرآورده شوند. یک روش مکانیکی برای گسیختگی و شکستن در مقیاس معقول برای بعضی زمان ها استفاده شده بودند, که بازده این روش 80درصد و متغیر بود. بحران جاری بازده را به 65 درصد کاهش داده و یک دوره طولانی مساله پیش بینی برای سعی در مقیاس تولید بالا و نرخ زیاد بود اما بازده باید خیلی بیشتر از 80 درصد شود.
مساله استاندارد TRIZدر بالاترین سطح , یک روش برای تولید نمودن محصول بدون ضایعات و بازده حدود 100 درصد پیدا نمود. فرمول بندی به عنوان یک راه حل استاندارد TRIZ به گونه ای است که بیان می داردکه مساله باید خودش را حل کند.
راه حل استاندارد دیگر TRIZ استفاده از الگوهای تکامل فنی است که در آن وسایل مکانیکی به وسیله فیلدها جایگزین می شوند. این ممکن است به ظاهر خیلی معمولی به نظر برسد اما آن محققان دارو ساز را به تجزیه و تحلیل همه منابع قابل دسترس در مساله هدایت می کند(سلول ها, دیواره های سلول ها, سیالی که سلول ها درآن هستند , حرکت سیال و … )و در نتیجه آنکه سه راه حل ویژه که دارای پتانسیل خیلی بالایی برای این مساله دارند وجود دارد:

1- دیواره های سلول باید توسط امواج صوتی شکسته شوند.(با استفاده از الگوی تکامل جایگزینی وسایل مکانیکی به وسیله فیلدها)
2- دیواره های سلول باید شکسته شوند به وسیله عمل تقسیم سازی همانند آنکه آنها از میان تسهیلات فرآیندی عبور می کنند.
3- یک آنزیم در سیال باید دیواره های سلول را بخورد و محتویات آن را در زمان مطلوب رها کند.

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

TRIZ دودسته از تناقضات را مشخص می کند:

· تناقضات فنی که در حقیقت موازنه کلاسیک مهندسی هستند. حالت مطلوب به دلیل سایر موارد دیگری که سیستم از آن جلوگیری می کند , قابل دسترسی نمی باشد. به عبارت دیگر وقتی بعضی عوامل بهتر می شوند , بعضی عوامل دیگر بدتر می گردند. مثالهای کلاسیک شامل:

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

راه حلهای استاندارد TRIZ، اشاره شده در شکل 1 ، در حدود بیشتر از 50 سال توسط محققانTRIZ توسعه داده شده اند و به روشهای مختلفی سازمان دهی گشته اند.
بعضی از این روشهای تحلیلی عبارتند از:

· نتیجه نهایی ایده آل
· تجزیه و تحلیل وظایف و Trimming
· موقعیت تمرکز ناقص (بیشتر مدیران پروژه در غرب با آن آشنا هستند: تجزیه و تجلیل ریشه ای مشکل )

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

· 40 اصل حل مساله
· اصول جداسازی
· قانون تکامل فنی و آینده نگری تکنولوژی

در دوره های حل مساله برای هر مساله فنی ، یک یا چند ابزار می تواند برای حل مساله استفاده شود. فلوچارت برای حل مساله در شکل 2 نشان داده شده است.
 

 

شکل 2 : فلوچارت برای استفاده از بعضی ابزارها و تکنیکهای TRIZ

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

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

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

TRIZ , 40اصل برای حل تناقضات فیزیکی و 4 اصل جداسازی برای حل تناقضات فیزیکی تعریف نموده است.


——————————————————————————–

صادق شهبازی
عضو هیئت علمی گروه خلاقیت و نوآوری مجتمع دانشگاهی ICTدانشگاه صنعتی مالک اشتر
عضو هیئت علمی مرکز پژوهشی خلاقیت شناسی ، نوآوری وTRIZ ایران
Email:sadegh.shahbazi@yahoo.com
 تهران- دانشگاه صنعتی مالک اشتر- مجتمع دانشگاهی ICT- گروه خلاقیت و نوآوری


منبع: مقاله دات نت
   1      2      3   >>
پیوندها
لوگو
دنیای مجازی
آمار وبلاگ
  • تعداد بازدیدکنندگان: 2243215