X
تبلیغات
مهندسی نرم افزار - مهندسی نرم افزار

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

کیفیت، هزینه کم! این یک پارادوکس است. نه این یک پارادوکس نیست، بلکه این بسیاری از باورهای دورنی ما است که با واقعیت های عینی دنیا ما در تضاد است. امروز می‌خواهیم با استفاده از یک قانون و یک تکنیک این پارادوکس را در وجود خود از بین ببریم.

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

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

چگونه می توان جیدوکا را در دنیای توسعه نرم افزار بکار برد؟ اگر شما از توسعه تست گرا (TDD) یا تست واحد (Unit Test) در فرآیند توسعه خود استفاده می کنید، جیدوکا را به کار می‌برید. شما تست های مورد نظرتان را می نویسید، اگر آنها شکسته شدند، شما کد خود را اصلاح می کنید تا بتوانید تست‌ها را با موفقیت تمام پاس کنید. اگر شما به آزمونهای خودتان وفادار باشید تا حد امکان اجازه نخواهید داد که خطاها در فازهای  بعدی کشف شوند و هزینه اصلاح آنها به شدت افزایش یابد. اگر شما در فرآیند توسعه خود از یکپارچه سازی پیوسته (Continuous Integration) استفاده می کنید و به همراه آن از مفهوم فیدبک پیوسته (Continuous Feedback) استفاده می کنید از جیدوکا استفاده می کنید. هر زمانیکه عمل Build در سرور CI شما با شکست روبرو شد. سرور CI با مکانسیمی که شما برای فیدبک پیوسته در نظر گرفتید، نتیجه را به اطلاع اعضای تیم خواهد رساند و اعضای تیم شروع به رفع مشکل خواهند کرد. دو مورد اشاره شده، بیشتر

مکانسیم فیدبک پیوسته (Continuous feedback mechanism)

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

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

پا‌نوشت: تصویر اول از کتاب روش کاربردی تحلیل نیازمندی های نرم افزار نوشته دوستان عزیز یوسف مهرداد، پویا شهبازیان و مظفر ایراف برداشت شده است. تصویر دوم هم از کتاب Continuous Integration برداشت شده است. 


برچسب‌ها: جیدوکا, Lean, Continuous Integration, Continuous feedback
نوشته شده توسط بهروز بختیاری  | لینک ثابت |

جدول زیر را در نظر بگیرید:

Daily Scrum Meeting

بدون در نظر گرفتن تعداد نفرات تیم یک جلسه زمان بسته (time-boxed) 15 دقیقه ای می باشد.

Sprint Planning Meeting

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

Sprint Review Meeting

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

Sprint Retrospective Meeting

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

 

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

به مثالهای بالا اشاره کردم تا به جمله ای برسم که واقعا با آن مشکل دارم. یعنی این جمله : " ﻧﻘﺶ ﻫﺎ ، ﻣﺼﻨﻮﻋﺎت ، روﯾﺪادﻫﺎ و ﻗﻮاﻧﯿﻦ اﺳﮑﺮام ﺗﻐﯿﯿﺮ ﻧﺎﭘﺬﯾﺮ ﻣﯽ ﺑﺎﺷﻨﺪ و ﻫﻤﭽﻨﯿﻦ ﭘﯿﺎده ﺳﺎزي ﺑﺨﺸﯽ از اﺳﮑﺮام ﻣﻤﮑﻦ ﻣﯽ ﺑﺎﺷﺪ و اﻟﺒﺘﻪ ﻧﺘﯿﺠﻪ ﺣﺎﺻﻠﻪ از اﯾﻦ ﻧﻮع ﭘﯿﺎده ﺳﺎزي اﺳﮑﺮام ﻧﺨﻮاﻫﺪ ﺑﻮد.". به نظر من وقتی در اسکرام از تغییر ناپذیری صحبت می شود ما در واقع با ذات و ماهیتی که اسکرام بر روی آن بنا شده است مخالفت می کنیم. پایه ها و زیر بنای اسکرام بروی تجربه گرایی بنا شده است، تجربه گرایی اعتقاد دارد که دانش از تجربه حاصل می شود. اجازه بدهید بر خلاف راهنمای اسکرام  تنها به همین چند کلمه اکتفا نکنیم و چند کلمه ای بیشتر درباره آن بدانیم. فرانسیس بیکن  یکی از بنیانگذاران فلسفه تجربه گرایی است، او معتقد بود که علم زمانی به دست می آید كه فرد محسوسات و جزئیات را به مشاهده و تجربه در آورد و برای استخراج قواعد به كلیات جمع آوری مواد روی آورد. اما این جمع آوری مواد، مشاهده و تجربه را سرسری نباید گرفت، و با نهایت دقت و تامل باید به كار برد. وی در شناخت واقعیت ها بر محسوسات و تجربه اهمیت زیادی قائل بود و تاكید داشت که جهت شناخت معارف و کسب علم باید از تاکید بیجا و افراط بر گفته ها و نوشته های دیگر علما پرهیز نمود  و با تکیه بر دیدگاه و جهان بینی خود در راه تاسیس علم و معرفت قدم برداشت  .پس بر اساس اصول پایه اسکرام یاد بگیریم که تنها به نوشته های روی کاغذ و قوانین مبدعان پایبندی بی اساس نداشته باشیم و اجازه بدهیم که این قوانین، رویدادها و نقش ها را با شرایط و فرهنگ خود تجربه کنیم و بر اساس تجربیات خود آنها را تغییر دهیم و برای تیم خود بهینه سازی کنیم.

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

1.       شفافیت (Transparency) : یعنی تمام اعضا تیم دقیقا بدانند با چه هدفی از اسکرام استفاده می کنند و اسکرام در فاز توسعه به کدام نیازهای آنها پاسخ می دهد.

2.       بازرسی (Inspection) : یک فرآیند کنترلی داشته باشید که بررسی کند که آیا رویدادها، قوانین و مصنوعات موجود در اسکرام به دلایل انتخابی شما پاسخگو است یا نه؟

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

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

گزیده:

The important thing is not your process.

The important thing is your process for improving your process.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

Not list پنجشنبه 16 تیر1390 22:58

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

برای حل این مشکل شما چه راه حلی ارائه می دهید؟ یکی از راه حلهای بسیار خوب و ساده ای که برای حل این مشکل  وجود دارد استفاده از یک Not list است. یعنی در همان اول مشخص می کنیم که ما می خواهیم چیکارهای را در داخل این پروژه انجام بدهیم و به طور روشن نیز مشخص می کنیم که چه چیزهای را نمی خواهیم انجام بدهیم. برای انجام این کار می توانیم از جدول شبیه جدول زیر استفاده کنیم.

چه چیزهای را می خواهیم انجام بدهیم

چه چیزهای را نمی خواهیم انجام بدهیم

1.       اضافه کردن مشخصات مشتریان

2.       اصلاح مشخصات مشتریان

3.       ...

1.       سیستم گزارشگیری دینامیک

2.       ویژگی آنلاین بودن سیستم

ویژگیهای که هنوز در مورد آن تصمیم گیری نشده است

1.       ارسال صورتحساب از طریق رسانه های مختلف

 

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

تیم شما چقدر اسکرام هست؟ پنجشنبه 5 خرداد1390 18:15

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

یکی از پیامدهای مشخص این دوره، صد در صد ترویج استفاده از اسکرام در تیم های توسعه نرم افزار در داخل کشور خواهد بود. اما آیا این تیم ها راه حلی دارند که تشخیص بدهند تیم توسعه آنها چقدر اسکرام هست یا نه؟ شاید پیشنهادهای مختلفی توسط این تیم ها ارائه بشود. ولی یکی از روشهای که میزان اسکرام بودن تیم را نشان می دهد و جای بررسی دارد، "نوکیا تست"  (Nokia test) می باشد که توسط کارشناسان شرکت نوکیا جهت پاسخ دادن به سوال بالا طراحی شده است. سوالات نوکیا تست به شرح زیر می باشد  که، دوستان می توانند با پاسخ به این سوال میزان اسکرام بودن تیم خود را بررسی کنند و در صدد رفع ایرادهای احتمالی استفاده از این متد برآیند. تست نوکیا از دو جنبه تیم را مورد بررسی می دهد.  

First, are you doing Iterative Development?

  • Iterations must be time-boxed to less than 4  weeks
  •  Is the software completely tested and working at the end of an iteration
  • Can the iteration start before specification is complete

The next part of the test checks whether you are doing Scrum (in Nokia's opinion):

  • Does the team know who the product owner is
  • Is there a product backlog prioritized by business value
  • Does the product backlog have estimates created by the team
  • Does the team generate its burndown charts and knows its velocity
  • Does the team have outside people disrupting the work of the team during the sprint

 

البته توجه شود که در بعضی از نسخه های این آزمون time-box را برای یک Iteration، 6 هفته در نظر گرفته اند. اما در نسخه های که فقط متد اسکرام را در نظر داشتند همان 4 هفته در نظر گرفته شده است.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

کتاب خوبم آرزو است شنبه 28 اسفند1389 23:8

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

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

انسان به امید زنده است ....

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

Three Simple Truths سه شنبه 17 اسفند1389 14:50

The following are three simple project truths that, once accepted, get rid of much of the drama and dysfunction we regularly see on software projects.

1.       It is impossible to gather all the requirements at the beginning of a project.

2.       Whatever requirements you do gather are guaranteed to change.

3.       There will always be more to do than time and money will allow.

Accepting the first truth means you are not afraid to begin your journey without knowing everything up front. You understand that requirements are meant to be discovered and that not proceeding until all are gathered would mean never starting.

Accepting the second means you no longer fear or avoid change. You know it is coming. You accept it for what it is. You adapt your plan when necessary and move on.

And by accepting the third, you no longer get stressed when your todo list exceeds your time and resources to deliver. This is the normal state for any interesting project. You do the only thing you can—you set some priorities, get the most important stuff done first, and save

the least important for last.

Once you accept these three simple project truths, much of the stress and anxiety traditionally associated with software delivery disappears. You are then able to think and innovate with a level of focus and clarity that escapes most in our industry.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

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

ما در پست ضایعات نرم افزاری، به بررسی مفهومی به نام ضایعات نرم افزاری پرداختیم و آن را از دیدگاه Lean مورد بررسی قرار دادیم. در این پست به بررسی همین موضوع از دید متدلوژیهای دیگر خواهیم پرداخت.

XP و YAGNI

در XP اصلی با عنوان YAGNI که سرنامی برای عبارت "You ain't gonna need it" می باشد و به معنی "شما به آن نیاز نخواهید داشت" می باشد وجود دارد. که این اصل بیان می کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعا به آن نیاز دارید، و نه وقتی که می فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعا روی آن تاکید دارد و اعلام می کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهد داشت آنرا الان پیاده سازی نکنید.

Scrum و قلب آن (Product backlog)

Product backlog را قلب Scrum می نامند. لیستی از ویژگیها و نیازمندیهای نرم افزار که بر حسب اولویت مرتب شده است و بر حسب همان ترتیب در عمل پیاده سازی خواهد شد. اما این اولویت توسط چه کسی یا کسانی و با چه منطقی انجام می شود؟ وظیقه اصلی اولویت دهی را Scrum بر عهده Product owner قرار می دهد و او بر حسب ارزشی که هر ویژگی برای مشتری ایجاد می کند آنها را مرتب سازی می کند. ویژکیهای با ارزش افزوده بالا در ابتدای لیست قرار می گیرند و به به ترتیب که در لیست پایان می رویم از ارزش افزوده هر ویژگی کاسته می شود و همچنین از اولویت پیاده سازی آن.

Lean و حذف ضایعات در هر نقطه و هر زمانی

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

خلاصه و هدف هر سه دیدگاه بالا اولویت بندی نیازمندیها و ویژگیهای برنامه بر اساس ارزشی است که برای مشتری تولید می کنند، انجام هر کار در زمان مناسب با توجه به درخواستهای مشتری و بازگشت سرمایه. ولی هر کدام آن را با شیوه و ابزارهای خود بیان می کنند. شاید بتوان گفت ما باید بیشتر از آنکه درگیر اسامی باشیم باید به فکر ابزارها و شیوه های باشیم که به تیم و فرآیند ما در موفقیت کمک می کند (پست RUP بهتر است یا Agile؟ از استاد مهرداد یا پست آقای شهبازیان در مورد الگوهای فکری می تواند جالب توجه باشد). شاید منظور و هدف من به روشنی از متن پایین قابل استنباط باشد.

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

در روزنامه شرق مورخه 21 مرداد 1389 مصاحبه ای با آقای حسن نراقی نویسنده کتاب معروف «جامعه شناسی خودمانی»درباره علل ضعف کارگروهی در جامعه ایرانی انجام شده بود که  واقعا زیبا و قابل تامل بود. از آنروز دنبال فرصتی بودم که نکاتی که برای خودم جالب بود را تایپ کنم و با دوستات دیگر به اشتراک بگذارم (متاسفانه سایت روزنامه شرق به روز نمی شود و آرشیو الکترونیکی آن موجود نیست فکر کنم از تاریخ اولین توقیف روزنامه دیگر به روز نشده است.).

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

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

تاثیر عوامل شخصیتی یا عوامل شخصیت ساز

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

شکل شخصیت انسان بیشتر زیر نفوذ تربیت است یا عوامل وارثتی؟

صلاحیت علمی در حودم نمی بینم که به این سوال جواب بدهم اما با تجربه ام می توانم بگویم که هر دو نقش دارند ولی شخصاً وزن تربیت را سنگین تر می دانم. در همین زمینه سوژه و بحث مورد نظر شما نسل تازه را نمی گویم. نسل خودم و حتی 10، 15 سال جوان تر را می گویم. تمامی دوران کودکی این نسل در فضای آمرانه و یک طرف شکل گرفت. پدر دستور می داد، مادر بزرگ سهم خودش را از جایگاه فرماندهی داشت. مادر هم همین طور. معلم، مدیر مدرسه و بخشدار و هگذا تا نهایت. جالب است حتی نظر کودک را را در مورد کفش و لباسی که قرار بود از آن استفاده کند هم نمی خواستند. خب این کودک بینوا کجا تمرین کرده است که تیمی کار بکند؟! یک نفر می گفته، بقیه اجرا می کردند. پس کودک تنها کاری که می تواند بکند این است که صبر کند تا بزرگ شود و همان بلایی را که سرش آورده اند سر نسل بعدی در بیاورد.  کار تیمی در فضای متقابل گفت و گو ها شکل می گیرد. یعنی به قول فرنگی این «دیالوگ»  است که تمرینی می شود برای کار تیمی نه «مونولوگ». شاید برایتان خنده دار باشد که ما در زبان فارسی لااقل تا آنجا که من می دانم برای ترجمه کلمه تیم مترداف فارسی نداریم. مثل اینکه اصلا ضرورتی برای درست  کردن آن وجود نداشته.

از دسته یا گروه نمی توانیم به جای «تیم» استفاده کنیم؟ (یک سال عالی با پاسخ عالی تر، این هم پست خودم در باره مسئله مشابه)

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

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

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

-        -  عدم علاقه به کار تیمی، برمی گردد به کا

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

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

1.      استفاده از فناوری روز و آموزش مداوم پرسنل

2.      عدم اضافه کار اجباری (در صورت اضافه کار، بایستی حقوق آن پرداخت شود)

3.      اعتماد و صداقت متقابل بین کارفرما و پرسنل و پرسنل با پرسنل

4.      شرایط محیط کار (امکان سفارش سازی محیط کار و استفاده از مبلمان کاری مناسب و استاندارد )

5.      امکان ترقی و رشد برنامه نویس در شرکت (در اکثر شرکتها امکان تغییر پست برای یک برنامه نویس در یک شرکت وجود ندارد، مگر اینکه به یک شرکت دیگر انتقال یابد.)

6.      عقاید مذهبی، سیاسی و ... هر فرد بستگی به خود فرد دارد و نباید در شرایط کاری فرد تاثیرگذار باشد.

7.      مشخص بودن نقش و سمت فرد در شرکت

8.      تعادل ساعات کاری با درآمد

9.      اولویت بندی افراد بر حسب تخصص و تجربه آنها نه بر حسب مدارک دانشگاهی افراد

10.  ایجاد ثبات کاری و حس ثبات در پرسنل (تمدید به موقع قرارداد و داشتن اطلاعات کافی و به موقع نسبت به نیازمندی یا عدم نیاز شرکت به من در دوره های بعدی )

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

12.  آگاهی کافی در مورد برنامه ها جاری و آتی شرکت و ...

13.    تشویق پرسنل در قبال انجام کارهای خوب و خلاقانه

14.  محدودیت ها و شرایط بی مورد در زمان قرارداد یا در حین کار

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

16.  توجیه نیروی تازه کار در مورد خط مشی شرکت، پروژه های در دست اجرا، روشهای تولید و پشتیبانی محصولات

17.  امکان نظارت پیوسته و منظم بر کار نیروها برای پیشرفت در انجام امور و بازدهی بهتر

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

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

تکمیل لیست نیازها و درخواست ها

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

یک روز خوب می آید که ....

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

توزيع Agile در سازمان چهارشنبه 23 تیر1389 15:20

ما می خواهیم به سمت Agile حرکت کنیم، XP، Scrum، Lean، FDD، AUP و شاید دهها اسم دیگر در این دسته از متدلوژیها وجو دارد که من نمی دانم و نشیدنم. ما باید از بین این اسامی کدام را انتخاب کنیم، چگونه انتخاب کنیم و چگونه به سمت آن حرکت کنیم؟ تفاوت اینها نسبت به هم چیست؟ نقاط قوت و ضعف آنها نسبت به هم چیست؟ 

اگر تیم یا سازمان شما Agile هست چه پاسخی به سوال بالا می دهید؟ روی پاسخ این مسئله فکر کنید و آنرا با دیگر دوستان به اشتراک بگذارید. در ادامه متن سعی می کنیم یک جواب واقع بینانه و قابل قبول به این سوال ارائه بدهیم.

 یک انتقاد

اجازه بدهید قبل از ارئه پاسخ به سوال بالا، موضوعی را بررسی کنیم که می تواند در ارائه پاسخ نهایی به سوال ما راهگشا باشد.

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

راه حل : تفکر سیستمی

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

 سطوح سازمان

در کتابهای مدیریت، سازمان را از لحاظ سطوح مدیریت به سه سطح مختلف تقسیم می کنند :

1-       سطح عالی (استراتژیک - راهبردی) : در این سطح مدیران وظیفه دارند اهداف بلند مدت، آزمانها و استراتژیهای سازمان را تعیین کنند.

2-       سطح میانی : این سطح وظیفه دریافت دستورات و برنامه ها را از سطح عالی سازمان و تبدیل آن به برنامه میان مدت، برنامه هایی اجرایی و زمانبندی شده و ابلاغ آن به سطوح پایین تر را بهعده دارد.

3-       سطح عملیاتی : این سطح مدیریت را سطح درگیر در فعالیت های اجرایی گویند. به عبارت دیگر وظیفه به اجرا گذاردن تصمیمات و دستورات مدیریت عالی و میانی را بعهده دارد.

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

سطوح سازمان

توزیع Agile در سازمان

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

برای پوشش هر سه سطح سازمان، سه گزینه XP،  Scrum و Lean  را انتخاب می کنیم و هر کدام از آنها را به یک سطح سازمان نگاشت می دهیم. Lean را به بالاترین سطح سازمان نسبت می دهیم یعنی زمانیکه بازگشت سرمایه و اهداف بلندمدت و استراتژی نمود پیدا می کند (به پست 14 اصل راه تویوتا مراجعه کنید). برای سطح میانی، Scrum را به کار می بریم یعنی سطحی که باید به سازماندهی تیمی، مدیریت زمان و تحویل پروژه تمرکز کرد. سطح آخر یا عملیاتی، جائیکه واقعا XP با آن تکنیک ها و اصول زیبای خود می تواند به تمام نیازهای عملیاتی توسعه نرم افزار جواب دهد.

نظر شما درباره این راه حل و پاسخ چیست؟


نحوه توزیع Agile در سازمان

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

ارزشهای پنجگانه سه شنبه 11 خرداد1389 11:31

در پست قبلی درباره ارزش و ضایعات نرم افزار صحبت کردیم و در این پست به ارزشهای كه در بعضی از متدلو‍ژیهای سبك مانند XP و Scurm وجود دارد كه زير بناي اصلی تكنیكهای اين متدلوژیها را تشكیل مي دهد خواهيم پرداخت و سعي خواهيم كرد كه با استفاده از این ارزشها به ائده ها و اصولی دست پیدا كنيم كه ضایعات را از فرآیند توسعه نرم افزار تا حد قابل قبولی حذف كنیم.

در جدول زیر ارزشهای مربوط به هر دو متدلوژی XP و Scrum آورد شده است ولی ما در اين پست فقط به بررسی ارزشهاي موجود در XP خواهیم پرداخت.

Scrum Values

XP Values

ارتباطات  (Communication)

ارتباطات  (Communication)

(Focus)

سادگی (Simplicity)

(Openness)

بازخورد (Feedback)

شجاعت (Courage)

شجاعت (Courage)

احترام (Respect)

احترام (Respect)

 

ارتباطات

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

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

XP برای ایجاد ارتباط در تیم ها،از تکنیک های استفاده می کند که ارتباط در تیم را اجباری می کند، تکنیک های مانند Planning Game، Pair Programming، Stand up meeting، تخمین کارها. یک تیم XP، از نقش مربی برای کنترل ارتباطات، حصول اطمینان از به کارگیری آن و تشویق برای سود جستن از تکنیک ها، به منظور غلبه بر مشکلات استفاده می کند.

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

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

 

سادگی

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

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

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

 

فیدبک

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

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

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

 

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

شجاعت

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

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

تغییرات را باید پذیرفت اما نه کورکورانه. تکینک های XP را به کار ببندید تا اعتمادتان به این تکنیکها افزایش پیدا کند. در این صورت به خودی خود، جسارت به کار بستن این تکنیک ها و ائده های جدید را پیدا خواهید کرد.

 احترام

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

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

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

یک سوال: ارتباط این پست با پست قبلی در چیست؟ یا چگونه با این اصول می توانیم تکنیکهای را طراحی کنیم که به نبرد با ضایعان نرم افزاری برویم.

 

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

ضایعات نرم افزاری پنجشنبه 9 اردیبهشت1389 9:15

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

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

هر چیزی که برای مشتری ایجاد ارزش نمی کند، به عنوان ضایعات در نظر گرفته می شود. در سیستم تولید تویوتا افرادی که در مرحله بعدی تولید تویوتا هستند به عنوان مشتری برای کارکنان مرحله فعلی در نظر گرفته می شوند.

 

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

اما چه چیزی را می توانیم در فرآیند توسعه نرم افزار ضایعات بنامیم؟ تویوتا هفت نوع اصلی ضایعات، بدون ارزش افزوده در کسب و کار یا مراحل تولید را مشخص کرده است که در جدول زیر نمایش داده شده است و برای هر کدام از این موارد نمونه معادل در توسعه نرم افزار آورده شده است.

نرم افزار

تویوتا

Extra features

 (تولید پیش از حد) Overproduction

Requirements

 (موجودی پیش از حد)Inventory

Extra Steps

() Extra processing steps

Finding Information

 (جابه جایی غیر لازم) Motion

Bugs not caught by tests

 (معایب) Defects

Waiting for decisions, Including customers

 (انتظار)Waiting

Handoffs

 (حمل و نقل غیر ضروری) Transportation  

 

از میان این هفت مورد کدام یک از آنها مهم تر است و باید فورا در جهت حذف آن اقدام کنیم؟ اکثر صاحبنظران توسعه نرم افزار  روی گزینه ویژگیهای اضافی (Extra features) توافق دارند. ویژگیهای اضافی! ویژگیها و عملکردهای از نرم افزار که مشتری از آنها استفاده نمی کند یا به ندرت از آن استفاده می کند.  طبق بررسی های انجام شده تقریبا فقط 20 درصد از ویژگیها و عملکردهای یک نرم افزار به طور مکرر استفاده می شود و 45 درصد از آن تقریبا اصلا استفاده نمی شود و 35 درصد آن به طور کم مورد استفاده قرار می گیرد، یعنی همان قانون هشتاد و بیست.

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

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

اما راه حل چیست؟

Ebey، شنیدن این کلمه شما را یاد چه چیزی می اندازید ؟ فروشگاه، خرید اینترنتی و شاید پیر امیدیار هموطنمان. اما اکثر ویژگیهای Ebay  چگونه توسعه داده شد؟ به شکل بسیار زیبا.  مشتریانی که پیشنهادی برای بهبود سایت داشتند (پیشنهاد مشتری = ارزش ) یک ایمیل به امید یار می فرستند و در سربعترین زمان ممکن آن ویژگی پیاده سازی می شد. نه نیازی به مرحله زمانبر تحلیل و طراحی فرآیندهای کلاسیک هست و نه در انتها خبری از ضایعات نرم افزاری.

مثال بالا یک نمونه ساده از چیزی که ما می خواهیم بدان برسیم بود، یعنی Agile. ما در اینجا به جای مشتریانی که برای امیدیار ایمیل می زدند Product owner یا on-site customer خواهیم داشت، به جای ایمیل ها، Story User ها که همراه با Product owner تهیه کردیم و توسط تیم اولویت بندی کردیم داریم و اجازه بدهید با کمی تحفیف Inbox را با Task Board یا Epic Board مقایسه کنیم و فیدبک کار را ایمیل مجدد یک مشتری در نظر بگیریم. اینها حداقل های هستند که با قرار دادنشان در جعبه ابزار خود و همراه کردن آن با یک فرآیند افزایشی می توانیم به فکر حذف ضایعات محصول خودمان باشیم و تصور یک فرآیند چابک را داشته باشیم. (چرا گفتم تصور؟ با اعتقاد به اینکه Agile یک فرهنگ است برای پاسخ، به نوشته زیر که بر گرفته از راه تویوتا است مراجعه کنید. )

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

 

حالا اگر در جعبه ابزار شما ابزارهای بالا همراه با ابزارهاي و تكنيك هاي بهبود كد و تست هست و یک تیم همراه با Product owner یا on-site customer چگونه به نبرد با این ضایعات خواهید رفت؟ اگر در جعبه ابزار شما ابزار دیگری هست که ریشه در خلاقیت تیمی شما دارد آنها را بیان کنید تا ما نیز آنها را در جعبه ابزار خود قرار دهیم. پس اجازه بدهید جعبه ابزار خود را باز کنیم و تا پست بعدی بدنبال یک راه حل خوب باشیم.

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

http://ooad.wordpress.com/

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

در پست قبل، نگاهي به تاريخچه تويوتا داشتيم. در اين پست چكيده اي از 14 اصل روش كاري تويوتا را بيان خواهيم كرد كه اين 14 اصل مي تواند يكي از پايه هاي اصلي فرهنگ Agile باشد.

چکیده ای از چهارده اصل روش کاری تویوتا

بخش اول: فلسفه بلند مدت

اصل اول: تصمیماتی مدیریتی خود را بر پایه فلسفه بلند مدت بنیان نهید، حتی به قیمت اهداف کوتاه مدت مالی.

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

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

·         مسئولیت پذیر باشید. در تصمیم گیری برای سرنوشت خود بکوشید. با اعتماد به نفس عمل کنید و به توانایی های خود ایمان داشته باشید. مسئولیت رفتار خود را بپذیرید و مهارتهایی که شما را قادر به تولید ارزش افزوده می کنند، حفظ کنید و بهبود بخشید.

اصل دوم: شیوه کاری پیوسته ای ایجاد کنید تا مشکلات را پدیدار کند.

·         شیوه های کاری را برای دستیابی به ارزش افزوده بالا و جریان کار پیوسته، مجددا طراحی کنید. سعی کنید میزان زمانی را که هر پروژه کاری ساکن و بی استفاده می ماند یا منتظر کسی است که روی آن کار کند، به صفر کاهش دهید.

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

·         جریان کار را در سراسر فرهنگ سازمانی خود نمایان سازید. ای امر کلید روند اصلاح مداوم و صحیح و پیشرفت افراد است.

اصل سوم: برای اجتناب از تولید اضافه، از سیستمهای کششی استفاده کنید.

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

·         با ذخیره مقداری اندک از هر محصول و ذخیره محدود آنچه مشتری از موجودی انبار برداشته و کم کرده است، کار خود را در انبارداریکالا کاهش دهید.

·         بیشتر پذیرای تغییرات هر روزه تقاضای مشتری باشید تا متکی بر سیستمها و برنامه های زمانبندی کامپیوتری برای پیدا کردن موجودی بی مصرف در انبار.

اصل چهارم: حجم کار را ثابت نگه دارید (هیجونکا) (مثل لاک پشت کار کنید نه مثل خرگوش)

·         حذف زوائد، تنها یک سوم معادله دستیابی به موفقیت است.  برداشتن بار اضافی از دوش افراد و تجهیزات و بر طرف کردن بی نظمی در زمانبندی تولید به همان اندازه دارای اهمیت است.

اصل پنجم: فرهنگ توقف برای رفع مشکل را بوجود آورید تا همان بار اول وضعیت کیفیت روشن شود.

·         کیفیت برای مشتری موجب ایجاد ارزش برای شما است.

·         از تمام روشهای مدرن تضمین کیفیت استفاده کنید.

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

·         سازمان خود را به سیستمهای حمایتی مجهز کنید تا به سرعت مشکلات را حل کنید و اقدامات متقضی را انجام دهید.

·         فلسفه توقف یا حل مشکل برای روشن کردن وضعیت کیفیت را از ابتدا، جزئی از فرهنگ خود کنید تا سرانجام بهره وری افزایش یابد.

اصل ششم: وظایف استاندارد، اساس پیشرفت پیوسته و قدرت بخشیدن به کار است.

·         برای حفظ پیش بینی پذیری، زمانبندی منظم، و بازده منظم عملکرد خود، همه جا از ارزشهای ثابت و قابل تکرار استفاده کنید. این امر اسا جریان کار و کوشش است.

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

اصل هفتم: از کنترل بصری استفاده کنید تا هیچ مشکلی پنهان نماند.

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

·         اگر صفحه نمایشگر کامپیوتر تمرکز کارگران را به هم می زند از به کار بردن آن اجتناب کنید.

·         سیستمهای دیداری ساده را در محلی که کار انجام می شود، طراحی کنید تا مدوامت جریان کار و اعمال نفوذ را مورد پشتیبانی قرار دهید.

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

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

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

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

 

بخش سوم: با بسط و گسترش افراد و شرکا به ارزش سازمان خود بیفزایید

اصل نهم: رهبرانی پرورش دهید که کار را کاملا درک کنند، با فلسفه کار زندگی کنند و آن را به دیگران بیاموزند.

·         بکوشید رهبرانی را از درون سازمان پرورش دهید، تا اینکه آنان را از خارج سازمان خریداری کنید.

·         یک رهبر خوب باید کار روزانه را با جزئیات کامل درک کند تا بتواند بهترین آموزگار فلسفه شرکت شما باشد.

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

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

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

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

اصل یازدهم: به شبکه های گسترده شرکا و فروشندگانتان با به چالش کشیدن و کمک به پیشرفت آنان، احترام بگذارید.

·         برای شرکا و فروشندگانتان احترام قائل باشید و با آنان به عنوان بخشی از کار خود بنگرید.

 

بخش چهارم: حل مستمر مشکلات ریشه ای، آموزش سازمانی را به جلو سوق می دهد.

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

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

·         بر اساس اطلاعاتی که شخصا مورد بررسی قرار داده اید، فکر کنید و سخن بگویید.

·         حتی مدیران و روسای بالا رتبه نیز باید شخصا بروند و مسائل را ببینند، در اینصورت دارای درکی بیش از یک درک سطحی از موقعیت خواهند بود.

اصل سیزدهم: تصمیماتی را به آهستگی با رای اکثریت و با در نظر گرفتن تمام گزینه های ممکن، اتخاذ نمایید و با سرعت به تصمیمات عمل کنید.

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

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

 

اصل چهاردهم: از طریق انتقادات پایان ناپذیر (هنسی)، و اصلاحات پیوسته، به یک سازمان یادگیرنده بدل گردید.

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

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

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

·         از هنسی (انتقاد و بازتاب) در مراحل مهم و پس از اینکه پروژه ای را به اتمام رساندید، برای تشخیص آشکار تمام کاستی های آن پروژه، استفاده کنید. برای اجتناب از انجام مجدد همان اشتباهات، اقدامات متقضی را انجام دهید.

·         بهتر از طریق مرسوم کردن بهترین شیوه ها، کار را بیاموزید تا اختراع مجدد چرخ در هر پروژه جدید و با هر مدیر جدید.

اينها خلاصه اي از چهارده اصل  راه تويوتا بودند كه اساس خط توليد تويوتا يا توليد ناب را تشكيل مي دهند. در پست هاي بعدي نمونه هاي از كاربرد اين اصول را صنعت نرم افزار بررسي خواهيم كرد.

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

راه تویوتا جمعه 6 فروردین1389 19:25

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

 قبل از اينكه به قسمت سوم "چگونه به سمت Agile حركت كنيم؟" برسيم، فكر كردم بهتر باشد قبل از اينكه به اصول چهاردگانه خط توليد تويوتا برسيم و يا همان اصول مبناي Lean، نگاهي به تاريخچه اين شركت داشته باشيم و ببينيم اين اصول از كجا و چگونه شكل گرفته اند. قبل از اينكه انديشه ها را ياد يگيريم، چگونه انديشيدن اين مردان بزرگ عالم مديريت و توليد را نيز بررسي كنيم.

خلاصه اي از تاريخچه تويوتا

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

داستان تویوتا از کجا شروع شد؟ شاید پاسخ این سوال خیلی عجیب باشد، یک دستگاه بافندگی دستی در سال 1894 که توسط ساکیچی تویودا که یک تعمیرکار مخترع بود ساخته شد که ارزان تر و بهتر از ماشینهای ریسندگی موجود بود. بعدها ساکیچی از طریق آزمون و خطا و در حالی که دستانش کثیف می شد، ماشین بافندگی خود را با نیروی بخار به حرکت در آورد (فرضیه ای که بعدها بخشی از اساس "راه تویوتا" یعنی گنچی گنباتسو شد). در سال 1926 کارگاه ریسندگی خودکار تویودا شروع به کار کرد که "شرکت مادر" گروه تویوتا محسوب می شود.

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

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

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

تاسیس شرکت با جنگ جهانی دوم همزمان شد و آمریکایها برنده این نبرد بودند، اما شانس با تویوتا بود چون برای ساختن مجدد ژاپن نیاز به کامیون بود و اینکار به تویوتا سپرده شد.  اما در این سالها اشغال توروم رشد چشمگیری داشت و در سال 1948، دیون تویوتا 8 برابر کل ارزش سرمایه آن بود. تویوتا برای جلوگیری از ورشکستگی، مذکراتی با کارمندان انجام داد و به جای اخراج آنها حقوق پرداختی کارمندان را 10% کاهش داد. اما این راهکار نیز جواب نداد و 600 نفر از کارکنان به صورت دواطلبانه از کار کنار گیری کردند و در انتها کیچرو مسئولیت ورشکستگی خودروسازی تویوتا را بعهده گرفت و از سمت رئیس شرکت استفعا داد بخاطر فلسفه بلند مدت شرکت.

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

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

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

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

یک سازمان یادگیرنده، چگونه سازمانی است؟

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

به‌ نظر ‌داجسون‌ سازمان‌ يادگيرنده‌ سازماني‌ است‌ که‌ با ايجادساختارها و استراتژي‌ها به‌ ارتقاي‌ يادگيري‌ سازماني‌ کمک‌ مي‌کند و داراي‌ توانايي‌ ايجاد، کسب‌ وانتقال‌ دانش‌ است‌ و رفتار خودش‌ را طوري‌ تعديل‌ مي‌کند که‌ منعکس‌ کننده‌ دانش‌ و ديدگاههاي‌ جديد باشد. مايکل‌ جي‌. مارکوارت در کتاب‌ ارزنده‌ خود به‌‌عنوان‌ « ساختن‌ سازمان ‌يادگيرنده‌» ، تعريف‌ نسبتاً جامعي‌ ارائه‌ کرده‌ است‌: «در تعريف‌ سيستماتيک‌، يک‌ سازمان‌ يادگيرنده‌ سازماني‌ است‌ که‌ باقدرت‌ و به‌ صورت‌ جمعي‌ ياد مي‌گيرد و دائماً خودش‌ را به‌ نحوي‌ تغيير مي‌دهدکه‌ بتواند با هدف‌ موفقيت‌ مجموعه‌ سازماني‌ به‌ نحو بهتري‌ اطلاعات‌ را جمع‌آوري ‌، مديريت‌ و استفاده‌ کند.»

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

دیسیپلین پنجم

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

peter senge the fifth discipline.pdf

داشتن دیدگاه مشترک (Shared vision): ايجاد ديدگاه مشترک يعني بنا شدن حس تعهد در گروه و ايجاد تصوير مطلوب از آينده با ويژگي پاسخ‌گويي فردي - که منجر به احساس تعهّد و مسئوليت در تمامي اعضاي گروه مي‌شود - هم‌خواني دارد. به اين معنا که تک‌تک اعضا نسبت به يادگيري خود و ديگران مسئول و متعهدند. (فصل مشترک کتابهای که تا به امروز درباره سازمانهای موفق خوانده ام یک نقطه بود، آرمان مشترک. آرمان مشترک، نقطه مشترک هر اجتماع موفقی است حال این اجتماع یک تیم، یک شرکت یک سازمان و یا یک کشور باشد.)

تفکر سیستمی (System Thinking) : ايجاد تفکر سيستمي مستلزم شناخت صحيح از کل سيستم، شناسايي نقاط قابل بهبود، درک نقاط قوت و تدوين راهکارهايي براي حل مشکلات است. به اين معنا که گروه، اطلاعات را به بحث و تبادل‌نظر و مشورت مي گذارد و هر يک با ديد سيستمي به تفکر جمعي، بازخورد گروهي و در نهايت خلق راهکارهاي جديد و توليد دانش در يک موضوع و بستر اقدام مي‌کنند.

یادگیری تیم (Team Learning)  : سازمانهای یادگیرنده با استفاده از ساز و کارهای گفتگو و بحث یادگیری گروهی را ترویج و در سازمان استمرار می بخشد. باید به گروهای سازمانی تفهیم شود که مجموع تلاش های آنان به عنوان یک گروه بیش از جمع مساعی تک تک آنها است. گروههای هماهنگ و منسجم می توانند به اتفاق هم یاد بگیرند و یادگیری آنان نیرویی شگفت آور برای رشد و پیشرفت به سازمان ارائه می دارد.

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

 قابلیت های شخصی (Personal Mastery) : تسلط و قابليت هاي شخصي عبارت است از نظامي كه در آن فرد به صورت مستمر ديدگا ه هاي شخصي خود را روشن تر و عميقتر مي نمايد، انرژي و توان خود را متمركز مي كند، صبر و بردباري خود را گسترش مي دهد و بالاخره آنكه واقعيات را منصفانه و بي غرض درمي يابد. با چنين تعريفي، تسلط و تواناييهاي شخصي يكي از اركان اساسي در سازمان هاي فراگير است.

گفتگو (Dialog) و مباحثه (Discussion) :

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

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

 

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

متن بالا حداقل های درباره سازمان یادگیرنده بودند. ولی این مفاهیم چگونه در دل Agile جا می گیرند؟ برای نمونه شما موضوع بحث و گفتگو را در نظر بگیرید و انواع جلساتی که در تیم های Agile برای کارهای مختلف تشکیل می شود مقایسه کنید، برای نمونه تکنیک Planning Poker.

گزیده : در زندگی دو نفر باش: یکی برای خودت، یکی برای دیگران. برای خودت زندگی کن و برای دیگران زندگی باش.  

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

چگونه به سمت Agile حرکت کنیم؟ چهارشنبه 28 بهمن1388 8:57

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

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

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

Lessons in Software from Alok Srivastava چهارشنبه 23 دی1388 18:36

These are my top lessons learned drawing from my years of software experience.  I am sharing them with you here.

Summary of Lessons
Here is an index of the lessons that follow:

  • Lesson 1. Software development is a team sport.
  • Lesson 2. More lines-of-code does not mean better software.
  • Lesson 3. The Cloud is an inflection point.
  • Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
  • Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
  • Lesson 6. Software maintainability is a key to longer life for any software.
  • Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
  • Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
  • Lesson 9. A great software engineer never stops working.
  • Lesson 10. Know the keys to writing great software; magic isn’t one of them...

Source : shapingsoftware.com

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

planning poker دوشنبه 9 آذر1388 23:8

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

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

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

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

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

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

در این روش ما مجموعه ای از کارت ها داریم، که بر روی هر کدام از آنها عددی نوشته شده است. این اعداد در اکثر موارد سری فیبوناچی یا یک سری مانند سری مقابل 0,1/2,1,2,3,5,8,13,20,40,100 می باشد.

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

در پاییز سال 1997، برین و پیج به این نتیجه رسیدند که موتور جستجوی بک راب به یک نام جدید نیاز دارد. پیج در یافتن یک نام چشمگیر که قبلا مورد استفاده قرار نگرفته باشد، دچار دردسر شده بود و لذا از شون اندرسون، هم اتاقی اش در خواست کمک کرد. آندرسون به یاد می آورد: «من به سمت تخته سیاه رفتم و با روش طوفان مغزی شروع به نوشتن اسامی روی آن کردم و او دائما می گفت نه، نه، نه. این کار چندین روز ادامه داشت. او رفته رفته مایوس می شد و ما یک جلسه دیگر طوفان مغزی تشکیل دادیم. من نزدیگ تخته سفید نشسته بودم و یکی از آخرین چیزهایی که به آن رسیدم این بود که "نظرت راجع به گوگل پلکس چیست؟" او شکل کوتاهتر این اسم را دوست داشت. من کلمه G-o-o-g-l-e را با املای غلط روی تخته سفید نوشتم  و حالا به چشم می آمد. لاری با آن موافقت کرد و بعدا در همان شب آن را ثبت کرد و  روی تخته سفید نوشت: google.com. شبیه یاهو یا آمازون، یک حلقه نه چندان دقیق اینترنتی به آن اضافه کرد و  روز بعد که به دفترم آمدم دیدم تامارا یاداشتی برایم گذاشته و نوشته است است تو املای آن را غلط نوشته ای. درست آن باید این باشد: G-o-o-g-o-l’»

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

سرگئی برین و لاری پیج: موسسین شرکت گوگل

کتاب the google story، کتاب بسیار خواندنی در مورد تاریخچه و سیر تکامل شرکت گوگل است، واقعا این شرکت سرنوشت جالبی دارد، که می تواند خیلی آموزنده باشد.خواندن این کتاب را به دوستان توصیه می کنم البته ترجمه فارسی کتاب نیز موجود می باشد با عنوان «سرگدشت شگفت انگیز گوگل» برای افراد مثل خودم که زبانشان زیاد خوب نیست.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

Question Until You Understand جمعه 17 مهر1388 6:27

“Accept the explanation you’ve been given. If you’re told where the problem lies, that’s where you look. Don’t waste your time chasing ghosts.”

Suppose there’s a major problem in an application, and they call you in to fix it. You aren’t familiar with the application, so they try to help you out, telling you the issuemust be in one particular module you can safely ignore the rest of the application. You have to figure out the problem quickly, while working with people whose patience may be wearing thin.

When the pressure is on like that, you might feel intimidated and not want to question too deeply what you’ve been told too deeply. To solve the problem, however, you need a good understanding of the big picture. You need to look at everything you think may be relevant — irrespective of what others may think.

Consider how a doctor works. When you’re not well, the doctor asks you various questions—your habits, what you ate, where it hurts, what medication you’ve been taking, and so on. The human body is complex, and a lot of things can affect it. And unless the doctor is persistent, they may miss the symptoms completely. For instance, a patient in New York City with a high fever, a rash, a severe headache, pain behind the eyes, and muscle and joint pain might be dismissed as having the flu, or possibly the measles. But by

probing for the big picture, the doctor discovers the hapless patient just returned from a vacation to South America. Now instead of just the flu, a whole new world of possible diagnoses opens up including dengue hemorrhagic fever.

Similarly, in a computer, a lot of issues can affect your application. You need to be aware of a number of factors in order to solve a problem. It’s your responsibility to ask others to bear with you—have patience—as you ask any questions you think are relevant.

Or, suppose you’re working with senior developers. They may have a better understanding of the system than you. But, they’re human. They might miss things from time to time. Your questions may even help the rest of your team clarify their thinking; your fresh perspective

and questions may give others a new perspective and lead them to find solutions for problems they have been struggling with.

“Why?” is a great question. In fact, in the popular management book The Fifth Discipline: The Art and Practice of the Learning Organization, the author suggests asking no fewer than five progressive “Why?”s when trying to understand an issue. While that might sound like a policy oriented more toward an inquisitive four-year-old, it is a powerful way to dig past the simple, trite answers, the “party line,” and the usual assumptions to get down to the truth of the matter.

The example given in the Fifth Discipline Field Book for this sort of root-cause analysis involves a consultant interviewing the manager at a manufacturing facility. On seeing an oil spill on the floor, the manager’s first reaction is to order it cleaned up. But the consultant asks, “Why is there oil on the floor?” The manager, not quite getting the program, blames the cleaning crew for being inattentive. Again, the consultant asks, “Why is there oil on the floor?” Through a progressive series of “Whys” and a number of employees across different departments, the consultant finally isolated the real problem: a poorly worded purchasing

policy that resulted in a massive purchase of defective gaskets.

The answer came as quite a shock to the manager and all the other parties involved; they had no idea. It brought a serious problem to light that would have festered and caused increasing damage otherwise. And all the consultant had to do was ask, “Why?”

“Oh, just reboot the system once a week, and you’ll be fine.” Really? Why? “You have to run the build three times in row to get a complete build.” Really? Why? “Our users would never want that feature.”

Really? Why?

Why?

Keep asking Why. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue.

   

What It Feels Like

It feels like mining for precious jewels. You sift through unrelated material, deeper and deeper, until you find the shining gem. You come to feel that you understand the real problem, not just the symptoms.

Keeping Your Balance

·         You can get carried away and ask genuinely irrelevant questions if your car won’t start, asking about the tires probably isn’t going to help. Ask “Why?” but keep it relevant.

·         When you ask “Why?” you may well be asked, “Why do you ask?” in return. Keep a justification for your question in mind before you ask the question: this helps you keep your questions relevant.

·         Don’t settle for shallow answers. “Because it used to..." is probably not a good answer.

·         “Gee, I don’t know” is a good starting point for more research not the end of the line.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

افزایش و فقط افزایش جمعه 16 مرداد1388 12:2

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

سوالاتی در آنالیز و طراحی یکشنبه 26 آبان1387 17:42

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

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

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

فقط سئوال این مدلی نباشه که سیستم حسابداری را چگونه طراحی می کنید!!!

و به پیشنهاد مدیر محترم بخش هم , اولین پست به فهرست بندی سوال اختصاص داده می شود.

سئوال اول رو خودم مطرح می کنم. تا دوستان دیگر هم ادامه دهند.

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

تست واحد (Unit Testing) جمعه 26 مهر1387 21:2

به تصویر بالا نگاه کنید فکر می کنید کلاس دیاگرام بالا متلعق به کدام قسمت از یک نرم افزار است. شاید حدس زدن آن در اولین مرحله برای خیلی ها مشکل باشد پس لطفا بر روی تصویر کلیک کنید تا تصویر را با اندازه واقعی مشاهده کنید و از نام متدها قضیه را حدس بزنید. تمام کلاس های بالا برای تست متدهای کلاس های نرم افزار یا همان تست واحد (Unit Test)  طراحی و پیاده سازی شده است. شاید اگر به سورس بسیاری از نرم افزارهای مشهور دسترسی داشته باشید، حتما مشابه این کلاس ها را در یک پکیچ جداگانه در سورس خواهید یافت (تصویر بالا مربوط به مولفه منوی  RadControls از شرکت Telerik است که حنما اکثر توسعه دهندگان وب با محصولات این شرکت آشنا هستند). پس اجازه بدهید در پایین به بررسی اصول و نحوه پیاده سازی تست های واحد بپردازیم.

تست واحد (Unit Testing):

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

هدف و فلسفه تست واحد

ما از تست واحد استفاده می کنیم تا نشان دهیم که واحد مورد نظر کاری را که ما فکر می کنم انجام می دهد یا نه.

 چرا باید تست واحد را انجام بدهیم؟

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

مزایا و منافع

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

1-      تست های واحد همانند یک سند اجرایی هستند که نشان می دهند شما انتظار دارید که کد نوشته شده در شرایط مختلف چگونه عمل کند. اعضای تیم می توانند برای درک عملکرد کد و اینکه چگونه آن را بکار ببرند به تست های واحد مراجعه کنند.

تست های واحد مستنداتی هستند که با تغییر و اصلاح کد بروز رسانی می شوند.

علاوه بر اینها نظرات و حدس های برنامه نویس را در تست ها می توانیم مستند سازی کنیم.

2-      به اشتراک گذاری کد با دیگران راحتتر است، چون اگر عضوی از تیم کد را طوری دستکاری کنید که درست کار نکند، اجرای تست ها با شکست روبرو می شود.

3-        با انجام تست های واحد، زمان انجام تست ها در سایر فازها کاهش می یابد.

4-      تست ها، انتظارات برنامه نویس را در مورد چگونگی عمل کردن یک قطعه کد، ارزیابی می کنند.

بهانه و مقاومت

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

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

2-      اجرای تست های نیاز به زمان زیادی دارید: یک آگاهی بازرگانی بود که احتمالا از تلویزیون خودمان آنرا مشاهده کرده اید، خانمی که باید غذا را آماده می کرد، به خرید می رود و ... خانم غذا را آماده می کرد آنرا تو آرام پز قرار می داد و دیگر تمام شد تا شب می توانست به کارهای دیگرش برسد. برای تست های که نیاز به زمانی زیادی برای اجرا دارند ما نیز همین کارها را انجام می دهیم. یعنی زمانی که باید کار دیگری را انجام دهم تست را اجراء می کنم چون اجرای تست فرآیندی خود کار است و به بقیه کارها می رسیم. یا در زمانهای بی کاری و یا آخر هفته. تست های را که نیاز به زمان زیادی دارند باید دسته بندی کرد و آنها را جدا از تست های دیگر و در دفعات کم اجرا کرد.

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

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

5-      چرا از تست کردن به صورت دستی، استفاده نکنیم؟ تست دستی امکان نفوذ خطاهای انسانی به سیستم را افزایش می دهد و همچنین تکرار کردن تست های دستی، بسیار مشکل تر است. برای اینکه تست های دستی را دوباره انجام بدهیم، به مستنداتی نیاز داریم که مراحل انجام تست ها را شرح بدهند. با تغییر کد، این مستندات به سرعت کهنه می شوند و این یعنی اینکه برای به روزنگهداشتن مستندات، باید کار اضافی انجام دهیم. 

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

(در قسمت بعدی به نحوه پیاده سازی تست های واحد و معرفی Nunit خواهیم پرداخت.)

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

مهندسی نرم افزار مبتنی بر مولفه : دوشنبه 18 شهریور1387 23:48

مهندسی نرم افزار مبتنی بر مولفه :

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

تفاوتهای  COP با OOP  :

  • COP مبتنی بر واسط می باشد ، در حالیکه OOP مبتنی بر اشیاست.
  •  COP تکنولوژی بسته بندی و توزیع می باشد ؛ در حالیکه OOP   یک تکنولوژی پیاده سازی محسوب می گردد.
  •  COP از قابلیت استفاده مجدد در سطح بالا پشتیبانی می کند ، در حالیکه OOP از قابلیت استفاده مجدد در سطح پایین پشتیبانی می کند.
  •  COP ، در اصل می تواند در هر زبانی نوشته شود ، در حالیکه OOP محدود به زبانهای شی گرا می باشد.
  •  در COP مولفه ها ارتباطات ضعیفی (Loosely Coupled) دارند در حالیکه در  OOP  اشیاء وابسته به همـدیگر از طریق پیاده سازی وراثت (ارث بری ) ، دارای ارتباطات محکم ( Loosely Coupled) می باشند.
  •  COP ، از واسطهای چند گانه و طراحی مبتنی بر واسط پشتیبانی می کند ، در حالیکه OOP ارتباطات واضحی از واسطها ی میان ابرکلاس و زیر کلاسها را فراهم نمی کند.
  •  COP از اتصـالات و اکتشافات پویا ( اتـصال در زمان اجرا ) پشتیبانی می کند، در حالیکه    OOPپشتیبانی محدودی از مـکانیزمهای ترکیب زمان اجرا و بازیـابی اشیا را فـراهم می آورد .
  •  COP مکانیزمهای بهتری برای ترکیب فراهم می کند ، در حالیکه OOP شکلهای محدودی از اتصالات را از طریق فراخوانی فراهم می آورد .
  •  COP  از خدمات امنیتی ، تراکنشها و غیره در سطح بالایی پشتیبانی می کند ، در حالیکه  OOP مجموعه  محدودی از خدمات امنیتی ، تراکنشها و غیره را   پشتیبانی می کند.
  •   در COP ، مولفه ها با در نظر گرفتن  قوانین اساسی Framework (چهارچوب ) مولفه ها ، طراحی می شوند  در حالیکه  OOP با در نظر گرفتن   اهداف شیء گرایی  طراحی می شوند  .

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

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

 

قابلیتها

COP

OOP

SP

تقسیم و غلبه

·                                 مدیریت پیچیدگی

·                                 تقسیم کردن یک مسئله بزرگ به بخشهای کوچکتر

 

 

 

یکپارچگی داده و تابع

·                                 یک نهاد نرم افزاری ، داده ها و عملیاتی که بر روی داده ها انجام می گیرد را ترکیب می کند.

·                                 بهبود دادن انسجام یا پیوستگی ( cohesion )

 

 

-

کپسوله سازی

·                                 کاربر یک نهاد نرم افزاری ، از چگونگی ذخیره داده ها و پیاده سازی توابع اطلاعی ندارد.

·                                 کاستن اتصالات ( پیوستگی)

-

مشخصه

·                                 هر نهاد نرم افزاری یک مشخصه (ویژگی ) منحصر به فرد دارد .

-

واسط

·                                 وابستگی بین مشخصات را نشان می دهد.

·                                 مشخصه (ویژگی) مولفه را به واسطها تقسیم می کند

·                                 کاستن وابستگیهای داخلی مولفه ای

-

-

پیکربندی

·                                 یک واحد انتزاعی که به طور مستقل می تواند توسعه یابد.

-

-

 

  • SP : Structured Programming
  • OOP : Object Oriented Programming
  • COP : Component Oriented Programming

 

مهندسی نرم افزار مبتنی بر مولفه :

برخی اوقات COP (Component Oriented Programming ) و CBSE (Component Based Software Engineering ) در نوشتار با همدیگر اشتباه گرفته می شوند . هر چند که CBSE یک مفهوم کلی است در صورتیکه  COP  فقط یه عنوان قسمتی از CBSE به کار برده می شود.

 CBSE= COA+COD+COP+COM

 

  • COA : Component Oriented Analysis
  • COD : Component Oriented Design
  • COP :  Component Oriented  Programming
  • COM : Component Oriented  Management

 COA ، COD ، COM به ترتیب  نشان دهنده تحلیل مبتنی بر مولفه ، طراحی مبتنی بر مولفه و مدیریت مبتنی بر مولفه می باشند . CBSE ، به تسریع کردن توسعه نرم افزار و کاهش دادن هزینه سیستم با ترکیب نمودن مولفه های نرم افزاری از پیش ساخته شده تاکید دارد .  طراحی ، توسعه و نگهداری مولفه ها ، برای استفاده مجدد فرآیند پیچیده ای است . CBSE شیوه های مهندسی نرم افزار و تکنیکهای مختلف نرم افزار  را پوشش می دهد چه از نظر عملی و چه از دیدگاه تئوریک که هنوز هم به طور کامل تعریف و توسعه نیافته اند.

در مهندسی نرم افزار  سنتی فرآیند توسعه نرم افزار در برگیرنده فعالیتها یا مراحل متوالی بود که عبارتنـد از : تحلیل ، طراحی ، برنامه نویسی ، تست و مجتمع سازی ( یکپارچه سازی ) . در CBSE ، مراحل اصلی  توسعه  ، تحلیل ، تولید و آماده سازی  و اسمبل کردن  می باشند. که در برنامه نویسی سنتی فعالیتهای تست و مجتمع سازی ( یکپارچه سازی ) جایگزین فعالیتهای  تولید و آماده سازی مولفه و اسمبل کردن مولفه در CBSE شده است .

 دو نوع اصلی از فعالیتها در CBSE وجود دارند :

  • DF ( Developing For reuse)  : توسعه برای استفاده مجدد.
  • DW ( Developing Withr reuse)  : توسعه با استفاده مجدد.

برای DF ، فعالیت توسعه می تواند با دنبال نمودن رویکردها یا دیدگاههای مهندسی نرم افزار سنتی تاکید بر استانداردهای مولفه ای سازماندهی گردد. برای نمونه هر مولفه ارائه کننده  در برگیرنده دو نوع واسط می باشد :

    1. واسط تامیین کننده : که خدمات ارائه شده توسط مولفه را تعریف می کند.
    2. واسط مورد نیاز (ضروری ): که مشخص می کند سیستم استفاده کننده از مولفه ، چه خدماتی را باید ارائه کند.

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

 از دیدگاه فرآیند مهندسی نرم افزار ، مولفه ها می توانند به 5 فرم مختلف طبقه بندی شوند ( یعنی مولفه در طی گذراندن 5  مرحله  حاصل می شود ):

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

 2.       واسط مولفه : فرم واسط تعریفی از مجموعه رفتارهای مولفه را ارائه می کند که می توانند توسط اشیا مولفه ای ارائه شوند.

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

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

 5.       شی مولفه ای : نمونه ای از مولفه نصب شده می باشد . مشابه OOP یک شی مولفه در COP یک شی با داده ها و مـشخصات ( ویـژگیها ی) منحصر به فرد می باشد ، که رفتار پیاده سازی شده را اجرا می کند یک مولفه نصب شده ممکن است چند شی مولفـه ای داشته باشد کـه نیازمـند ویـژگیهای صـریح و روشن می باشد.

 

نوشته شده توسط احمدی  | لینک ثابت |

تست نرم افزار (قسمت 2) جمعه 15 شهریور1387 18:7

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

1.       در کتاب هنر تست نرم افزار - the art of software testing خواندم (و به نظرم کاملا منطقی می آید) که هدف نهایی از تست نرم افزار یافتن باگهای بیشتر است و نه چیز دیگر! البته ادله محکم و قابل قبولی نیز برای این تعریف ارایه میکند.

2.       در متن اشاره کرده ای که "یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم ...". در حوزه تست نرم افزار سناریوی ذکر شده در متن (سناریوی آفتابی-sunny scenario) کاملا لازم است اما سناریوی دیگر (سناریوی بارانی-rainy scenario) که هدف آن کشف اشکالات نرم افزار در مواجهه با مقادیر نادرست (مثلا عدم نمایش پیغام خطای مناسب) است نیز از اهمیت بالایی برخوردار است.

3.       . در تجربیاتی که داشتم Equivalence Partitioning و Boundary Value Analysis را در تستهای جعبه سیاه نیز به کار بردم که منجر به صرفه جویی در زمان و احتمال کشف خطاهای بیشتری شد.
و البته بعضی از موارد دیگر را می توانید تحت عنوان اصول اساسی تست نرم افزار از وبلاگ ایشان دنبال کنید و البته به همه دوستان توصیه می کنم حتما پست های اول وبلاگ ایشان را که بیانگر اهمیت تست نرم افزار می باشید را حتما مطالعه کنند. و البته از همه دوستان می خواهم که نواقص و اشکالات را بیان کنند تا به مطالبی با کیفیت خوب برسیم.

تست نرم افزار عموما در چهار سطح مختلف صورت می گیرد که این چهار مرحله به صورت ترتیبی انجام می پذیرند و عبارتند از :

  1. تست واحد (Unit testing)
  2. تست مجتمع سازی  (Integration Testing)
  3. تست سیستم (System Testing)
  4. تست پذیرش (Acceptance Testing)

تست واحد (Unit testing) :

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

تست مجتمع سازی  (Integration Testing) :

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

تست سیستم (System Testing) :

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

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

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

و ...

 تست پذیرش (Acceptance Testing) :

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

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

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

و ...

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

تست نرم افزار (قسمت 1) سه شنبه 5 شهریور1387 19:52

فرمانده گروهان: بزرگترین عاملی که یک سازمان یا شرکت را از سازمانهای و شرکت های دیگر متمایر می کند چیست؟

...

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

...

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

تست فقط می تواند وجود خطاها را نشان دهد نه عدم وجود آنها را

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

وارسی:  "آیا محصول درستی را می سازیم؟"

اعتبارسنجی: "آیا محصول را به درستی می سازیم؟"

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

استراتژی تست

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

استراتژی جعبه سیاه:

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

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

1.       بررسی اینکه سیستم نیازمندهای عملیاتی و غیر عملیاتی را تامین می کند یا نه.

2.       اعتبارسنجی ورودیها

3.       بررسی مقادیر مرزی برای متغییرها: به یک متغییر مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند می دهیم و سیستم را در این شرایط تست می کنیم.

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

5.       بررسی رفتار سیستم در برابر پردازش ورودها و پرس و جوهای بزرگ و سنگین

6.       ...

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

functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing, system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing , ….

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

if (name=="Lee" && employeeNumber=="1234" &&
    employmentStatus=="RecentlyTerminatedForCause") {
    send Lee a check for $1,000,000;

    }

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

 

استراتژی جعبه سفید

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

در یک استراتژی آزمایش جعبه سفید ما عموما موارد زیر را مورد توجه و بررسی قرار می دهیم:

1.       بررسی سطر به سطر کد (Code coverage): در این حالت باید سیستم را به گونه ای اجراء و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجراء شده است.

2.       بررسی همه انشعاب ها در کد برنامه (branch) : در کد برنامه باید تمام عبارت های شرطی ( if elseها و Switch case ها)   را تک به تک مورد بررسی قرار داد. به این صورت که در یک عبارت if else هم فسمت if و هم قسمت else هر کدام بصورت مجزا یکبار اجراء شوند. 

3.       بررسی همه حلقه ها در برنامه : حلقه ها در نرم افزار نقش اساسی دارند، چون می تونند با اشتباه جزئی مقدار زیادی از منابع را مصرف کرد برای مثال شرط خروج از حلقه به اشتباه هیچ وقت True نشود. برای نمونه حلقه ها را با ورودی بزرگتر از شرط خروج حلقه چک کنید یعنی حلقه اصلا اجر نشود. تستی طراحی کنید که حلقه دقیقا یکبار اجراء شود، تستی طراحی کنید که حلقه در یک بازه خاص اجراء شود و ....

4.       مدیریت خطای مطلوب : برسی اینکه اگر به یک متد یک ورودی نامعتبر وارد شود، نحوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد؟

5.       بررسی امنیت : سیستم را از این جهت که چگونه در برابر دسترسی های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند مورد بررسی قرار می دهد. در اینجا  ما باید مکانهای از کد را که داده ها را اعتبارسنجی و مدیریت می کنند، دسترسی به منابع یا عملیات مهم و حیاتی را انجام می دهند را بررسی کنیم.

6.       ...

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

Basis Path Testing, Equivalence Partitioning/Boundary Value Analysis, Method Coverage, Statement Coverage, Branch Coverage, Condition Coverage, Data Flow Testing, Flow Graphs Revisited, ….

 

ادامه دارد.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

مولفه چیست ؟ چهارشنبه 26 تیر1387 23:55

 

مولفه چیست ؟

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

تغییرات اساسی در توسعه نرم افزار به صورت زیر معرفی شده است :

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

2.       بایستی روش دستی توسعه نرم افزار توسط متدهای مهندسی جایگزین شود.

3.       بایستی برنامه نویسی مبتنی برنحو یا گرامر (Syntax   ) با اسمبل کردن یا ترکیب نمودن مولفه های مبتنی بر واسطها و معانی ( Semantic )  جایگزین گردد. بدیهی است تا زمانیکه ما نتوانیم روشهای رسمی و سیستماتیکی به سمت توسعه نرم افزار مبتنی بر مولفه را کشف کنیم این چنین تغییرات اساسی رخ نخواهد داد. مولفه های نرم افزاری در روشهای مختلف از نقطه نظر ساده تا مشکل تعریف شده است .

چهار تعریف از مولفه های نرم افزاری اولین بار در کارگاه بین المللی CBSE در آوریل 1998 به صورتهای زیر ارائه شده است :

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

o        مولفه های نرم افزاری زمان اجرا  بسته ای از یک یا چندین برنامه های مدیریت شده به عنوان یک واحـد می باشند که بـه طـور پویا می تواند به برنامـه مقید (متصل)  شود. و از طـریق واسطـهای مـستند شده که در زمان اجـرا کشف می شود در دستـرس قـرار مـی گیرد.( Gartner Group ).

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

o        مولفه تجاری ،پیاده سازی نرم افزاری یک فرآیند تجاری یا راه کار تجاری را ارائه می کند که شامل شرح ، پیاده سازی و توسعه نرم افزار می باشند که به عنوان یک قطعه قابل استفاده مجدد از یک سیستم بزرگتر می باشد . ( Wojtek Kozaczynski SSA )  .

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

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

مولفه های سخت افزاری و نرم افزاری  :

در طول 50 سال گذشته  تکنولوژی تولید سخت افزار کامپیوتری  اساسا تغییر کرده است تراشه های مجتمع (IC)  و مدارهای مجتمع با مقیاس زیاد (VLSI )، بلوکهای سازنده اساسی هستند که سریعترند و هزینه کمتری را در بر دارند .در مهندسی سخت افزار روش مبتنی بر مولفه به طور گسترده در ساخت قطعات جدید مورد استفاده قرار گرفته است ( یعنی استفاده از قطعات سخت افزاری از پیش ساخته شده ).

 

   مهندسین سخت افزار نیاز دارند که بازدهی طراحی را  با مونتاژ نمودن بلوکهای قابل استفاده مجدد از قبیل : Microprocessor ، DSP ، on chips encryption /decrepti و غیره بدست بیاید.  روش مبتنی بر مولفه  ، کیفیت و قابلیت اعتماد محصولاتی که هر کدام از مولفه هایش به خوبی تست شده است را افزایش می دهد . هر چند که ، تغییر چشمگیری در تولیدات نرم افزاری وجود نداشت . هر مـحصول نرم افزاری جـدید نیاز به طـراحی داشت و برنامه نویسان کد منبع را خط به خط می نوشتند تا اینکه برنامه تمام شود . پیشرفت بزرگ توسعه نرم افزار در طول 50 سال گذشته از برنامه نویسی خط به خط با استفاده از کد ماشین تا برنامه نویسی خط به خط با استفاده از زبانهای برنامه نویسی سطح بالا صورت گرفت . زبانهای برنامه نویسی سطح بالاچندین مزایای مهم را عرضه کرد که بازدهی برنامه نویسی را در نتیجه گرد آوری تکنیکها ( اصلاح کرد ) پیشرفت داد .

چه تفاوتهایی بین مولفه های سخت افزاری و نرم افزاری وجود دارد ؟

منطقا ، سخت افزار و نرم افزار کامپیوتر در قابلیت محاسبه شان مشابه هم هستند . بدین معنی که هر عملی که توسط نرم افزار انجام می شود می تواند به طور مستقیم با سخت افزار ساخته شود. از طرف دیگر هر دستوری که توسط سخت افزار اجرا می شود ، می تواند توسط نرم افزار شبیه سازی شود . به طور نمونه مولفه های سخت افزاری  IC  ها هستند که در برگیرنده مدارهای مجتمع با مقیاس متـوسط (MSI ) ، مدارهای مـجتمع با مـقیاس زیاد ( LSI)  و مـدارهای مجتمع با مقیاس خیلی زیاد ( VLSI  ) هستند. اینها مولفه های مفیدی هستند به خاطر اینکه مدارهای منطقی توابع ورودی و خروجی شان به خوبی تعریف شده و نیازی ندارند که به طور مستقیم با دنیای بیرون در تعامل باشند  و ارتباط بین مولفه های سخت افزاری توسط گذرگاه سیستم فراهم شده است. در مورد مولفه های نرم افزاری برخی مشکلات وجود دارد ، یکی اینکه نمی توان این مولفه ها را به سادگی توابع ورودی و خروجی بیان کرد و دیگر اینکه برخی از مولفه های نرم افزاری بایستی با کاربران  دیگر  وسیله های فیزیکی که در محیط موجود هستند تعامل داشته باشد . به همین دلیل آنها را نمی توان به سادگی سخت افزار تلقی نمود. مهم است ذکر این نکته که مدلهای کامپیوتری  که به خوبی تعریف شده اند وجود دارند مثل جبر بولی برای طراحی مدار در ساختن مولفه های سخت افزاری. جبر بولی روش مقرون به صرفه ای برای توصیف توابع مداربندی دیجیتالی فراهم می کند .یک تابع مطلوب داده می شود ، جبر بولی می تواند برای توسعه ، پیاده سازی ساده شده ای را که از طریق قوانین جبری عمل می کند ، بکاربندد.

مدل کامپیوتری برای مهندسی نرم افزار مبتنی بر مولفه چیست؟

بدیهی است که یک مدل کامپیوتری برای توسعه نرم افزار مبتنی بر مولفه مشابه جبر بولی که برای مهندسی سخت افزار مبتنی بر مولفه استفاده می شود مورد نیاز است . منطق (Hoar) هوار یک قاعده ای را برای بازبینی صحت برنامه ، مبتنی بر ساختار برنامه ، پیش شرطها و پس شرطها ارائه می کند .همانطور که ما از زبانهای برنامه نویسی خط به خط به سمت توسعه مبتنی بر مولفه حرکت می کنیم یک قاعده ای را برای بدست آوردن رفتار ( Behavior )  مولفه ها و اطمینان از صحت تعاملات مولفه ها نیاز داریم.

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

ü       اول اینکه برخلاف تراشه های حافظه که به طور فیزیکی در هر زمان تولید می شوند تولید مولفه های نرم افزاری با نسخه های متفاوت ، تکثیر (نسخه برداری  ) دقیق در هر زمان است .

ü       دوم اینکه محیط مولفه های نرم افزاری به طور محتمل برای هر استقرار ( نصب ) جدید تغییر می کند .

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

 برای نمونه ، قابلیت اعتماد مولفه های سخت افزاری تابع چهار عامل زیر می باشد :

1. خطا در طراحی

2.       خطا در تولید

3.       نقص فیزیکی

4.       فرسودگی فیزیکی و شیمیایی

 

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

 

نوشته شده توسط احمدی  | لینک ثابت |

چرا برنامه نویسی مبتنی بر مولفه اهمیت دارد؟

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

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

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

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

     *غلبه بر پیچیدگی   * مدیریت تغییر  * قابلیت استفاده مجدد.

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

مدیریت تغییر:تغییرات در مهندسی نرم افزار ذاتی است ، تغییر خواسته های کاربران ، تغییر مشخصه ها ، تغییر کارکنان ، تغییر بودجه ، تغییر تکنولوژی و غیره.یکی از اهداف اساسی مهندسی نرم افزار تاکیید بر اهمیت مدیریت تغییر می باشد.برنامه نویسی مبتنی بر مولفه یک روش موثر به نام برنامه ریزی برای تغییر و ساخت طراحی را  برای برخورد با تغییرات  در مهندسی نرم افزار فراهم آورده است . مولفه ها به آسانی با خواسته های جدید و در حال تغییر وفق داده می شوند . مهندسین نرم افزار توافـق کرده اند که روش بـهتر در برخـورد با تغییرات دائمی در ساخت سیستمها ، مولفه های قابل استفاده مجدد می باشند.

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

* جعبه سفید  * جعبه خاکستری  * جعبه سیاه  .

جعبه سفید ( White Box  ) :  بدین معنی است که منبع (Source  ) یک مولفه نرم افزاری قابل دسترس می باشد و می تواند مطالعه شود ، استفاده مجدد گردد ، وفق داده شود یا تغییر یابد.

 

 جعبه سیاه (  Black Box ) :  مبتنی بر اصل مخفی نمودن اطلاعات می باشد . این واسط سرویسهایی که یک  Client  ممکن است از یک مولفه در خواست کند را مشخص  می کند . مولفه پیاده سازی واسطی که  Client  بر آن تاکید دارد را فراهم می کند ، از آنجاییکه  واسطها بدون تغییر باقی می مانند مولفه ها می توانند به طور داخلی تغییر کنند بدون اینکه کاربر را تحت تاثیر قرار دهد .

جعبه خاکستری (Gray Box ) :  چیزی ما بین جعبه سفید و جعبه سیاه می باشد.

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

نوشته شده توسط احمدی  | لینک ثابت |

تیم و انگیره 2 پنجشنبه 30 خرداد1387 21:15

1)      نظریه X  و Y مک گریگور

افرادیکه تحت رهبری شما قرار دارند دارای چه ویژگیهای هستند؟ آیا آنها افراد مسولئیت پذیر هستند یا نه؟ قدرت خلاقیت آنها در چه حد است؟ با چه عواملی میزان انگیزه آنها بالا می رود؟ شما می توانید به این سوالاتی نسبت به دید خودتان پاسخ دهید، اما فردی به نام مک گریگور نگرش مدیران را در مورد افرادی که تحت رهبریشان قرار دارند را اینگونه بیان می کند: در هر گروه و تیمی، دو دسته از افراد وجود دارند، گروه X و گروه Y اما ویژگیهای این افراد:

گروه X

گروه Y

افراد تنبل و از کار بیزارند.

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

افراد مسئولیت گریز هستند.

افراد مسئولیت پذیر هستند.

برای انگیزش افراد باید از مشوقهای مادی استفاده کرد.

افراد توسط کارشان برانگیخته می شوند.

افراد دوست دارند تحت کنترل دیگران باشند.

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

قدرت خلاقیت در افراد کم است.

قدرت خلاقیت در افراد زیاد است.

توقع حصول نتایج کوتاه مدت

توقع حصول نتایج بلند مدت

تاکید بر استفاده صرف از امکانات و ظرفیت های موجود(عدم میل به پیشرفت)

کوشش برای توسعه منابع و افزایش ظرفیت و خدمات (میل به پیشرفت)

 

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

2)      نیازهای مک کللند

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

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

1-       نیاز به کسب قدرت 2- نیاز به برقراری ارتباط با دیگران 3- نیاز به موفقیت و پیشرفت

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

3)      نظریه انتظار

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

Many Eyes دوشنبه 6 خرداد1387 19:37

When the Declaration of Independence was still a draft, Benjamin Franklin, sitting beside Thomas Jefferson, revised Jefferson's wording of "We hold these truths to be sacred and undeniable" to the now-famous phrase, "We hold these truths to be self-evident." According to biographer Walter Isaacson, Jefferson was distraught by Franklin's edits. So Franklin, aware of his friend's state, sought to console Jefferson by telling him the tale of his friend John Thompson.

John had just started out in the hat-making business and wanted a sign for his shop. He composed his sign like so:

Before using the new sign, John decided to show it to some friends to seek their feedback. The first friend thought that the word "hatter" was repetitive and unnecessary because it was followed by the words "makes . . . hats," which showed that John was a hatter. The word "hatter" was struck out. The next friend observed that the word "makes" could be removed because his customers would not care who made the hats. So "makes" was struck out. A third friend said he thought the words "for ready money" were useless, as it was not the custom to sell hats on credit. People were expected to purchase hats with money. So those words were omitted.

The sign now read, "John Thompson sells hats."

"Sells hats!" said his next friend. "Why, nobody will expect you to give them away. What then is the use of that word?" "Sells" was stricken. At this point there was no use for the word "hats" since a picture of one was painted on the sign. So the sign was ultimately reduced to:

In his book Simple and Direct, Jacques Barzun explains that all good writing is based upon revision [Barzun]. Revision, he points out, means to re-see. John Thompson's sign was gradually revised by his friends, who helped him remove duplicate words, simplify his language, and clarify his intent. Jefferson's words were revised by Franklin, who saw a simpler, better way to express Jefferson's intent. In both cases, having many eyes revise one individual's work helped produce dramatic improvements.

The same is true of code. To get the best refactoring results, you'll want the help of many eyes. This is one reason why extreme programming suggests the practices of pair-programming and collective code ownership [Beck, XP].

Refactoring to Patternsمنبع :

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

تیم و انگیزه پنجشنبه 26 اردیبهشت1387 17:29

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

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

نظریه سلسله مراتب نیازهای انسانی

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

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

هرم مازلو

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

افرادی که در تیم عضویت دارند یا در محیط کار با آنها تعامل داریم، اغلب نیازهای دو سطح اول آنها ارضاء شده است. لذا، مدیران باید به برآورده کردن نیازهای سطوح دیگر هرم مازلو بپردازند، برای نمونه در کتاب سامرویل به موارد زیر اشاره شده است:

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

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

3-      برای برآورده کردن نیازهای خودشکوفایی، باید در کارشان مسئولیت به آنها واگذر شود. آموزش هایی برای آنها در نظر گرفته شود تا بتوانند مهارت های خود را افزایش دهند. (اما به نظر من این مرحله بستگی به شخصیت و شناخت درونی هر فرد از خود دارد)

تئوری بهداشت و انگیزش هرزبرگ:

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

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

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

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

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

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

چند پیشنهاد:

1.     One of your most important jobs as project manger is keeping the team motivated and constantly monitoring them to make sure they motivated.

2.     A really effective way to motivate your team to set up a reward system. But make sure that they understand exactly what they`re begin rewarded for and it MUST be fair, or it could backfire!

3.     Training is another great way to keep a team motivated. When people fell that they`re growing professionally, they stay more involved and get more excited by their work.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

تیم یا گروه، تشابه اسمی یا شنبه 7 اردیبهشت1387 13:32

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

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

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

“brown-bag session” - روز آزاد سه شنبه 7 اسفند1386 19:10

 

“Don’t share what you know—keep it to yourself. It’s to your advantage to be the Smart One on the team. As long as you’re smart, you can forget about those other losers.”

 

Your team has developers with different capabilities, experience, and skills. Each person has different strengths and expertise. That mix of diverse talents and backgrounds makes it an ideal environment for learning.

On a team, it’s not enough if you personally know a lot. If other members of your team are not as knowledgeable, the team isn’t as effective as it could be: a well-educated team is a better team.

While working on projects, you need to use terms and metaphors to clearly communicate your design concepts and intent. If most members of your team are not familiar with these ideas, it will be hard for you to be effective. Also, suppose you’ve taken a course or gone to a symposium. You generally lose what you don’t use. You need to bring what you have learned into your team. Share it with the rest of the team when you get back.

Find areas where you, or someone in your team who is knowledgeable, can help the rest of the team come up to speed (this has the added advantage that you can discuss how topics apply specifically to your applications or projects).

A “brown-bag session” is a great way to share knowledge in a team. Pick a day of the week, for instance Wednesday (generally any day other than Monday and Friday works well). Plan to get together over lunch so you don’t have to worry about running into other meetings or getting special permission. Keep the cost low by having folks bring their own lunch (in a brown bag, of course).

Each week, ask one member of your team to lead the discussion. He or she will present some concepts, demo a tool, or do just about anything that’s of interest to the team. You can pick a book and go through some specific sections, items, or practices from it.2 Do whatever works.

 

Is Everyone Better Than You? Good!

Legendary jazz guitarist Pat Methany offers this advice: “Always be the worst guy in every band you’re in. If you’re the best guy there, you need to be in a different band. And I think that works for almost everything that’s out there as well.”

Why is that? If you’re the best on the team, you have little incentive to continue to invest in yourself. But if everyone around you is better than you are, you’ll be keenly motivated to catch up. You’ll be on top of your game.

 Plan to start with the person leading the session that week speaking for fifteen minutes or so. Then you can open the topic for discussion so everyone can present their ideas and discuss how the topic might be relevant to your projects. Discuss benefits, provide examples from your own applications, and plan to get follow-up information.

These brown-bag sessions can be very valuable. It raises the industry awareness of the whole team, and you can personally learn a lot from them as well. Wise managers tend to value team members who raise the value of other members, so presenting can directly help your career, as well.

 

Raise the bar for you and your team. Use brown-bag sessions to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project.

 What It Feels Like

It feels like everyone is getting smarter. The whole team is aware of new technology and starts pointing out how to apply it or points out pitfalls to watch for.

Keeping Your Balance

• Reading groups that go through a book chapter by chapter are very helpful, but pick good books. Learning XYZ in 7 Days with Patterns and UML is probably not a good book.

• Not all the topics will be winners or even seem appropriate at the moment. Pay attention anyway; it wasn’t raining when Noah built the ark.

• Try to keep it in the team. A catered lunch in the auditorium with PowerPoint slides loses some of the intimacy and discussion opportunities.

• Stick to a regular schedule. Constant, small exposure is agile. Infrequent, long, and drawn-out sessions are not.

If some team members balk at coming to the lunch, bribe them with pizza.

• Stretch beyond purely technical books and topics; pertinent nontechnical topics (project estimation, communication skills, etc.) will help the team as well.

• Brown-bag sessions aren’t design meetings. Overall, you want to focus on discussing general topics that are relevant to your application. Solving specific issues is usually better left to a design meeting.

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

(رنگ قرمز در متن شخصیت منفی، رنگ سبز در متن شخصیت مثبت)

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

مالکیت جمعی (Collective Ownership) سه شنبه 30 بهمن1386 13:37

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

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

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

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

شاید شما هم یک یا چند دوست صمیمی داشتید یا دارید که با هم پشت یک کامپیوتر نشستید و برنامه های متنوعی را نوشتید، و از این کار لذت برده اید، اما شاید در آن لحظات متوجه نشده اید که شما در حال یکی از تکنیک های XP به نام برنامه نویسی دو نفره هستید.

برنامه نویسی دونفره، نوعی از برنامه نویسی است که دو برنامه نویس باهم و در کنار هم پشت یک کامپیوتر می نشینند و بر روی یک قسمت از کد برنامه، طراحی و یا تست نرم افزار کار می کنند. یکی از جفت ها که کد برنامه را تایپ می کند یا مستندات مربوط به طراحی را می نویسد را راننده (driver) می نامند. فرد دیگر را هدایت کننده (navigator) می نامند که کارهای راننده را نظارت می کند و سعی می کند اشکلات او را کشف کند. خطاهای مانند syntax errors، فراخوانی یک تابع به صورت اشتباه، پیاده سازی یک الگوریتم به شیوه ناکارا و ....  در واقع از بعد دیگر می توان گفت  در برنامه نویسی دو نفره، افراد مختلف با دانش ها و مهارت ها مختلف می توانند مهارتشان را ترکیب کنند تا یک مسئله مشکل را حل کنند. فرض کنید شما کسی هستید که مهارتتان در پایگاه داده در سطح عالی هست و دوست شما کسی که در برنامه نویسی شی گرا مهارت خیلی زیادی دارد در اینصورت شما می توانید کدی را بنویسید که به صورت بهینه و کارا به پایگاه داده دسترسی پیدا کند.

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

1.       کیفیت: در این شیوه ما کدی با کیفیت بالا خواهیم داشت چون اکثر خطاها و اشتباهات در همان مرحله اول تشحیص داده می شود.

2.       صرفه جویی در زمان: چون ما کدی با کیفیت بالا خواهیم داشت، زمان تست و تغییرات در سیستم کاهش خواهد یافت.

3.       افراد شاد: برنامه نویس های که با این تکنیک کار می کنند، اکثرا خوشحالتر و شادتر از زمانی هستند که به تنهایی کار می کنند. برای نمونه شما فشار کمتر را تحمل می کند چون همیشه کسی را در کنار خود دارید که به شما کمک کند و این باعث می شود که شما خیلی خوشحالتر باشید.

4.       اعتماد و روحیه همکاری بالا: در این شیوه شما تک و تک افراد تیم خود را به خوبی خواهید شناخت و باعث می شود که شما به آنها اعتماد کند و روح همکاری بخاطر شناخت عمق افراد بالا برود.

5.       دو نفر همیشه بهتر از یک نفر است.

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

7.       مالکیت جمعی (این گزینه یکی از نقاط مورد علاقه من است و بعداً در یک پست مجزا آنرا بررسی خواهیم کرد.)

 

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

فکر کنم چند ماه قبل یک ایمیل برایم رسیده بود که محتوایش برایم جالب بود. احتمالا اکثر دوستان نیر ایمیل های مشابه را دریافت کردند یا از متن آن که در پایین می خواهیم به آن اشاره کنم از طریق سایت های دیگر باخبر شده اند. ایمیل مربوط بود به یک مسابقه که توسط شرکت مایکروسافت پشتبانی و حمایت می شد و مربوط بود به ارائه یک مقاله در مورد ویژوال استودیو 2008 یا پیاده سازی یک برنامه در این محیط و تاکید مسابقه نیز بر روی ویژگیهای جدید این محیط مانند Linq و ... بود. و جایزه مسابقه از نظر مالی فکر کنم مبلغ جالبی بود ولی دقیقا یادم رفته است که مبلغ جایزه نفر اول چقدر بود. فکر کنم آنزمان هنوز نسخه اصلی برنامه نیز ارائه نشده بود. همانروز ایمیل را به چند تا از دوستانم نشانم داد و گفتم که فکر می کنید هدف شرکت مایکروسافت از انجام این مسابقه چه می تواند باشد؟ (این سوال را حالا از تک تک شما دوستان نیز دارم) حتی یکی از دوستانی که کمی روی این سوال بحث کردیم یکی از طرفداران دوآتشه شرکت بورلند و محصولاتش بودند و می گفتند که حتی توی یک مسابقه مشابه که شرکت بورلند چند سال قبل روی محیط دلفی برگزار کرده بود جز منتخبان مسابقه بودند. ولی اکثر پاسخ دوستان، پاسخ های بود که به نظر من زیاد جالب نبودند چون خود شرکت مایکروسافت خودش می توانست بدون هیچ زحمتی خودش اینکارها را انجام دهد. یا بعضی از پاسخ ریشه ها در محیط و فرهنگی بود که ما در داخل کشور با آن روبرو هستیم. ولی یکی از دلایل عمده که به نظر من می تواند وجود داشته باشد موضوعی است که به عینا در کتاب کسب و کار به شیوه بیل گیتز (Business the bill gates way) به آن اشاره شده است (قسمت پایین از کتاب اشاره شده است ولی نوشته های با رنگ آبی نظرات شخصی من هستند):

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

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

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

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

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

منتظر نظرات شما هستم.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

حق با مشتری است یا نه؟ جمعه 2 آذر1386 21:46

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

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

Listen to Users

 

Users are always complaining. It’s not your fault; they’re just too stupid to read the stinkin’ manual. It’s not a bug; they just don’t understand. They should know better.”

Andy once worked for a large company that developed products for high-end Unix workstations. This wasn’t the sort of environment where you could just run setup.exe or pkgadd to install the software. You had to copy files and tune various settings on your workstation.

Andy and his team thought everything was going well, until one day Andy was walking past the tech support area and overheard a support engineer laughing loudly into the phone: “Oh, it’s not a bug; you made the same mistake everyone does.” And it wasn’t just this one engineer.

The whole department was chuckling at the poor, naïve, stupid customers.

Apparently there was a situation where you, the hapless customer, had to go tweak some obscure system file to contain a magic value, or otherwise the application would not run at all. No error message, no crash, just a big black screen followed by an abrupt exit. Granted, a line in the installation instructions mentioned this fact, but apparently some 80% of the customers missed that fact and had to instead submit to abuse via the company’s tech support line.

Whether it’s a bug in the product, a bug in the documentation, or a bug in our understanding of the user community, it’s still the team’s problem, not the user’s.

Then there was the case of the expensive manufacturing shop-floor control system that none of the users would use. It seems the first step to using the system was to log on with their name and password, and the majority of the workers in this plant were illiterate. No one have ever bothered to ask them or get their feedback, so a completely useless system was installed. (The developers in question had to retool the entire GUI to be picture-based at huge expense.)

We go to great lengths to get feedback from code using unit tests and such, but it’s all too easy to ignore the feedback from users. So not only do you need to talk to real users (not their managers or a surrogate

such as a business analyst), you need to listen to them.

Even if they sound stupid.

Every complaint holds a truth. Find the truth, and fix the real problem.

What It Feels Like

You don’t get irate or dismissive of stupid complaints; you can look past that and see the real, underlying problem.

Keeping Your Balance

• There is no such thing as a stupid user.

• There is such a thing as a stupid, arrogant developer.

• “That’s just the way it is” is not an answer.

• If the code can’t be fixed, perhaps the documentation and training

can be.

• Your users may have read all the documentation and will remember everything about your application all the time.

But probably not.

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

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

اصل (DRY (Don't Repeat Yourself جمعه 4 آبان1386 23:30

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

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

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

تعریف اصلی DRY

DRY: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

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

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

class Line {

public:

Point start;

Point end;

double length;

};

تکه کد بالا را در نظر بگیرید، فکر می کنید مشکلی روی این کد وجود دارد یا نه. شاید در نگاه اول این کد مشکل نداشته باشد اما در این تکه کد اصل DRY رعایت نشده است. صفت length را در نظر بگیرید، مقدار این صفت با توجه به مقادیر start و end محاسبه می شود و با تغییر هر کدام از این صفات، آن نیز تغییر می کند (همیشه این نوع تکرار کد را با افزونگی در پایگاه داده مقایسه می کنم و می کویم صفتی که  قابل محاسبه از روی صفات دیگر باشد، نیازی به ذخیره سازی ندارد. می شود نرمالسازی در پایگاه داده را مفهومی مشابه این اصل دانست). پس بهتر است این تکه کد به صورت زیر تغییر کند.

class Line {

public:

Point start;

Point end;

double length() { return start.distanceTo(end); }

};

 

می توانیم به سادگی راه حل های زیادی برای رهایی از این دام پیدا کنیم و فکر می کنم نیاز زیادی به بحث روی این موضوع نیست، البته پیشگیری مثل همیشه بهترین شیوه درمان است. اما دوست دارم ادعای جالبی که آقایان  Andy Hunt و  Dave Thomas(اصل DRY، برای اولین با توسط این دو نفر ارائه شده است.) رابیان کنم و دوست دارم نظر شما را در مورد این ادعا بدانم. به نظر شما مرحله نگهداری یک برنامه  از چه زمانی شروع می شود؟ نمی دانم دقیقا پاسخ شما چیست، اما پاسخ دو نفر بالا به این صورت است که برنامه نویسان همیشه در مرحله نگهداری هستند.  و تنها در 10 دقیقه اول یعنی زمانیکه شما برای اولین با یک تکه کد را تایپ می کنید در مرحله نگهداری قرار ندارید و سپس شما بارها و بارها یک تکه کد را تغییر می دهید تا به هدف خود برسد و اینها جزء مرحله نگهداری هستند. حال نظر شما چیست؟

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

اصل open-closed شنبه 31 شهریور1386 0:15

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

مهم نیست که شما کجا کار می کنید، روی چه محصولی کار می کنید و با کدام زبان برنامه نویسی، برنامه نویسی می کنید. یک چیز، همیشه می تواند رخ بدهد. تغییر.

تنها یک چیز تغییر نمی کند. تغییر.

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

اصل open-closed

موجودیت های نرم افزاری برای نمونه کلاس ها، توابع و پیمانه ها باید برای توسعه باز باشند(اجازه داشته باشند)، اما برای تغییر باید بسته باشند(اجازه تغییر را ندارند).

 

یک تشبیه زیبا(فکر می کنم به زبان اصلی خیلی زیباتر است.)

 Code should be closed(to change) like the lotus in the evening. Yet open(to extension) like the lotus flower in the morning.

 

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

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

یک طراحی می تواند به این صورت باشد که شما یک کلاس Shape تعریف می کنید، که اشکال دیگر از آن کلاس به ارث می برند، و یک کلاس دیگر مثلا با نام DrawManager تعریف می کنید که لیست اشیاء را نگهداری می کنید و مسئول رسم اشکال مختلف بر روی صفحه نمایش است. مثلا متدی یا نام DrawAllShape داریم که با توجه به هر نوع هر شکل تابع مخصوص رسم ان شکل را فراخوانی می کند. در این متد ما کدی شبیه کد پایین خواهیم داشت.

        If TypeOf S Is Circle Then

            DrawCircle()

        ElseIf TypeOf S Is Triangle Then

            DrawTriangle()

        Elseif ...

        End If

 

 

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

حالا تصور کنید که کلاس انتزاعی یا یک اینترفیس به نام Shape تعریف کرده ایم که دارای یک متد به نام  Draw می باشد، و تمام اشکال این متد را به ارث می براند و متد Draw را بازنویسی می کنند. در این حالت هر شکلی  جدیدی به برنامه اضافه شود، کلاس shape را به ارث می برد و متد Draw را بازنویسی می کند و نیازی نیست که در کلاس DrawManager   تغییری ایجاد کنم و این کلاس، تنها متد Draw هر شکل را برای رسم آن شکل فراخوانی می کند. همانطوریکه مشاهده کردید ما در این حالت در کد مربوط به هیچ یک از کلاس های موجود تغییری ایجاد نکردیم اما برنامه خود را توسعه دادیم.

در بسیاری از الگوهای طراحی یکی از مهمترین ویژگیهای که در نظر گرفته شده است، اصل open-closed می باشد. برای نمونه می توانید الگوی TEMPLATE را بررسی کنید. ما باید بعضی از تغییراتی که می تواند در سیستم رخ دهد را، پیش بینی کنیم و با استفاده از مفهوم abstractions از سیستم خود در مقابل این تغییرات حفاظت کنیم. در واقع می توان گفت که کلید اصل open-closed دو مفهوم abstractions و encapsulation می باشد.                                                                                                          

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

رابطه وراثت((inheritance :

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

روش اول:

در این روش برای کل سلسله مراتب کلاس، یک جدول در نظر می گیریم. که ساختار جدول به صورت زیر خواهد بود.

{صفات سوپر کلاس، صفات مختص زیر کلاس ها و یک فیلد نوع کلاس (موجودیت)}

فیلد نوع برای ذخیره اینکه رکورد مورد نظر مربوط به اطلاعات کدام کلاس است به کار می رود.

برای مثال برای نمودار بالا، ساختار زیر را خواهیم داشت:

{شماره شناسایی، نام، نام خانوادگی، مقطع، رشته، درجه، سابقه تحصیل و نوع}

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

 

روش دوم:

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

{صفات سوپر کلاس و صفات مختص زیر کلاس}

برای مثال برای همان نمودار مثال قبل دو جدول زیر را خواهیم داشت:

استاد{شماره شناسایی، نام، نام خانوادگی،درجه، سابقه تحصیل }

دانشجو{شماره شناسایی، نام، نام خانوادگی، مقطع، رشته }

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

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

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

اما مزیت این روش نسبت به روش اول اینست که در این روش دیگر ستونهای با مقادیر Null را نخواهیم داشت.

 

روش سوم:

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

برای مثال برای نمودار مثال اول، اگر صفت شماره شناسایی را برای هر شخص منحصر بفرد در نظر بگیریم.خواهیم داشت:

شخص{شماره شناسایی، نام، نام خانوادگی}

استاد{شماره شناسایی، درجه، سابقه تحصیل}

دانشجو{شماره شناسایی، مقطع، رشته}

این روش بهترین گزینه برای ما می باشد.زیرا دقیقا هر کلاس را به یک جدول جداگانه و مستقل نگاشت می کند. و هر تغییری در یک کلاس فقط در جدول مربوط به آن کلاس تاثیر خواهد گذاشت و بر خلاف دو روش قبلی، روی جدول های دیگر تاثیر نخواهد گذاشت. در این روش نه افزونگی داده داریم و نه ستونی با مقدار Null.

 

رابطه association:

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

اما برای نگاشت این رابطه بین دو کلاس به رابطه بین دو جدول(برای هر کلاس یک جدول در نظر می گیریم.) چه کاری باید انجام دهیم؟

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

 

برای مثال برای نمودار شکل بالا جدول های زیر را خواهیم داشت.

آدرس{کد پست ده رقمی، شهر، خیابان و ...}

شخص{کد پستی ده رقمی و صفات کلاس شخص}

 

رابطه تجمع (aggregation) و رابطه ترکیب (composition):

رابطه تجمع، یک رابطه بین یک واحد کل و جزء است. در این رابطه، بزای موجودیت کل، یک جدول و برای هر یک از کلاس های جزء نیز یک جدول طراحی می کنیم. در هر کدام از جدول های مربوط به اجزاء جزء، کلید اصلی (یا یکی از کلید های کاندید) جدول مربوط به واحد کل را می آوریم.

 

برای نمونه برای شکل بالا خواهیم داشت:

ماشین{صفات مربوط به ماشین}

تایر{کلید اصلی جدول ماشین و صفات مربوط به تایر}

موتور{کلید اصلی جدول ماشین و صفات مربوط به موتور}

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

تبدیل رابطه ترکیب نیز شبیه رابطه تجمع است اما به یک تفاوت. چون در رابطه تجمع اشیاء تشکیل دهنده کل به واحد کل وابسته هستند ونمی توانند بدون آن به حیاتشان ادامه بدهند. با حدف شی کل، اشیاء جزء نیز باید حذف شوند. در واقع ما در اینجا باید یکپارچکی ارجاعی (Referential Integrity) را رعایت کنیم.

در اینجا من به در خواست یکی از دوستان فقط به بررسی روابط بین کلاس ها پرداختم. ولی دوستانی که به این موضوع علاقه دارند می توانند به مقاله Database Modelling in UML در سایت www.sparxsystems.com.au مراجعه کنند.

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

سرفصل و منابعی که توسط وزارت علوم برای درس مهندسی نرم افزار 1 و 2 در نظر گرفته شده است.

 

مهندسی نرم افزار 1

سر فصل مطالب

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

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

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

مراجع

1.       Bentley, Barlow and Toppan, System Analysis and Design Methods, 199.

2.       Yourdon, Modern Structured Analysis, Perntice-Hall, 1989.

3.       Fitsgerald and A. Fitzgerald, Fundamentals of System Analysis, 3rd Edition, John Wiley, 1987.

4.       Hawryszkiewgcz, Introduction to System Analysis and Design, 2nd Edition, Prentice-Hall, 1992.

5.       E.M.Awad, System Analysis and Design, 2nd Edition 1985.

6.        K.E.Kendall and J.E. Kendall, Systems Analysis and Design, 2nd Edition, Prentice-Hall, 1992.

7.       B. Boehm, Software Engineering, 4th Edition, Addison-Wesley, 1996.

8.       A. Sommerville, Software Engineering, 4th Edition, Addison-Wesley, 1996.

9.        R. S. Pressman, Software Engineering, A Practitioners Approach, 4th Edition, Mc Graw Hill, 1996.

 

مهندسی نرم افزار 2

سر فصل مطالب

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

مراجع

1.       A. Sommerville, Software Engineering, 4th Edition, Addison-Wesley, 1996.

2.       R. S. Pressman, Software Engineering, A Practitioners Approach, 4th Edition, Mc Graw Hill, 1996.

3.       D. Bell, I. Morrey and J. Pavgh, Software Engineering, A Practical Approach, Prentice-Hall, 1992.

4.       I. Jacobson, Object-Oriented Software Engineering, John Wiley, 1993. 

 

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

واژه نرم افزار دوشنبه 20 شهریور1385 16:29

واژه نرم افزار

 

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

یک توصیف از نرم افزار می تواند بصورت زیر باشد:

  1. دستورات(برنامه های کامپیوتری) که در صورا اجرا شدن باعث انجام عملیات مورد نظر می شوند.
  2. ساختمان داده هایی که باعث می شوند برنامه ها بطور مناسبی اطلاعاتی را دستکاری کنند.
  3. مستندان سیستم که برای تشریح ساختار سیستم بکار می روند.
  4. مستندات کاربر که برای تشریح چگونکی کار با سیستم بکار می روند.

 

نرم افزار یک محصول یا ابزاری برای تحویل محصول ؟

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

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

نرم افزار به عناون ابزاری برای تحویل محصول، به عنوان مبنایی برای کنترل کامپیوتر( سیستم های عامل)، تبادل اطلاعات(شبکه ها) و ... عمل می نماید.

 

دسته بندی محصولات نرم افزاری :

  1. محصولات کلی (pre-written): این دسته از محصولات سیستم های مستقلی اند که توسط یک شرکت تولید کننده تولید می شوند و به بازار عرضه می گردند و مشتریان می توانند بر حسب نیاز آنها را تهیه کنند.به عنوان مثال پایگاه داده ها (MSSQL, MySQL, …)، واژه پردازه ها(MSWord,…)
  2. محصولات سفارشی(bespoke): این دسته از محصولات سیستم های هستند که توسط مشتری خاص سفارش داده می شوند. این محصولات توسط پیمانکاران نرم افزاری برای آن مشتری تولید می شوند. نمونه های از این نرم افزار ها عبارتند از : سیستم اندازه گیری برای دستگا ههای الکترونیکی، سیستم های برای کنترل ترافیک هوایی و ...

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

 

نوشته شده توسط بهروز بختیاری  | لینک ثابت |

روابط (مفاهیم شی گرایی) سه شنبه 7 شهریور1385 22:11

رابطه ها:

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

یک لینک(Link) رابطه بین دو شی است. یک رابطه(association) یک ارتباط بین دو کلاس هست.

رابطه بین کلاس ها (اشیاء) به سه شکل متفاوت تقسیم می شود:

  1. ارتباط (association)
  2. رابطه تجمع (aggregation)
  3. رابطه ترکیب (composition)

 

ارتباط (association) :

ساده ترین شکل رابطه، ارتباط می باشد. که یک رابطه نظیر به نظیر(peer-to-peer) بین دو شی می باشد. یک شی بطور ساده درباره شی دیگر می داند بهمان طریقی که یک فرد ممکن است فرد دیگری را بشناشد. یک ارتباط یه یک کلاس امکان می دهد تا درباره صفات و رفتارهای کلاس دیگر بداند.

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

برای مثال کلاس تحویل دار درباره صفات و رفتارهای کلاس حساب بانکی می داند و کلاس حساب درباره صفات و عملیات تحویل دار می داند. بنابراین این دو کلاس می توانند پیغامهایی را به یکدیگر ارسال کنند.

 

رابطه تجمع (aggregation):

رابطه تجمع، یک رابطه بین یک واحد کل و جزء است. در رابطه تجمع یک کلاس می تواند شامل نمونه های از کلاس های دیگر نیز باشد. برای مثال یک کلاس ماشین را در نظر بگیرید، که خود از چندین کلاس دیگر مانند یک کلاس موتور، چندین کلاس لاستیک و تعدادی کلاس دیگر برای سایر بخش ها تشکیل شده است.

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

برای مثال یک کلاس برای تیم پروژه در نظر بگیرید. و یک کلاس برای کارمندان شرکت در نظر بگیرید. تیم پروژه، از کارمندان شرکت تشکیل شده است. اما ممکن است یک تیم پروژه منحل شود در حالیکه کارمندان به کار خود در شرکت ادامه می دهند.

 

رابطه ترکیب (composition):

رابطه ترکیب، شبیه رابطه تجمع می باشد اما با یک تفاوت:

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

برای مثال یک پنجره در سیستم عامل ویندوز را در نظر بگیرید، یک پنجره از چندین شی تشکیل شده است بعنوان مثال دکمه Minimize، Maximize، Close ، یک منو و .... زمانیکه یک شی پنجره ایجاد می شود همزمان با آن تمام دکمه ها و منو ایجاد می شود. با بستن پنجره تمام اشیاء، پنجره، دکمه ها و منو از بین می روند. امکان ندارد بدون وجود یک شی پنجره یک شی منو ایجاد شود و به کاربر نمایش داده شود یا با بستن و از بین رفتن شی پنجره، شی منو از بین نرود.  

رابطه ترکیب همان حذف پخش شونده (cascading deletion) است. در یک رابطه ترکیب هنگامیکه رکورد اصلی حذف می شود تمام رکورد های مرتبط با رکورد اصلی حذف می شوند.

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

 

 

نوشته شده توسط بهروز بختیاری  | لینک ثابت |