مطلب جالبي از Matt Quail با عنوان When Java is dead مطالعه كردم كه در نوع خودش جالب بود.

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

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

در آدرس زير مي‏توانيد تاريخچه‏اي از زبانهاي برنامه‏سازي را پيدا كنيد:

• مجموعه‏اي از ۲۵۰۰ زبان برنامه‏سازي كامپيوتري
• تاريخچه زبانهاي برنامه‏سازي كامپيوتري

قوانين بسيار زبادي حاكي از آن هستند كه موضوعات طبيعت مقادير ثابتي دارند و از شكلي به شكل ديگر تبديل مي‏شوند.

– قانون بقاي ماده و انرژي

– قانون P * V / T= Cte

– قانون بقاي پروژه در دانشگاه

– قانون بقاي دمپايي در خوابگاه

Matt Quail در نوشته‏اي با نام “قانون اول Matt در پیچیدگی نرم‏افزار” بحث جالبي را مطرح مي‏كند. اين نكته كه “پيچيدگي مسئله مقدار ثابتي است” و مي‏توانآن را مخفي كرد ولي هنوز وجود دارد. تجرید تنها كمك مي‏كند كه پيچيدگي را به جايي منتقل كنيد كه مديريت و كنترل آن آسان‏تر است. (تفرقه بنداز و حكومت كن).

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

حركت به سمت تجريدهاي سطح بالاتر در حوزه راه حل (Solution Domain) – مانند زبانهاي خاص حوزه مسئله DSL يا چارچوبهايي مانند J2ee, .NET – در همين راستا هستند.

اما فراموش نكنيد: انسانها اكثراً در حال حل مسائلي هستند كه خود آنها را به وجود آورده‏اند.

تجرید(Abstraction) به عنوان یکی از مبانی اصلی در رهیافت شیءگرایی و به طور کلی مهندسی نرم‏افزار پذيرفته شده است. تجريد بهمعناي برجسته‏سازي آن چه كه براي خواننده مهم است و حذف آن چه كه براي خواننده مهم نيست، تعريف شده است. ‍‍‌[Mary Shaw].

تجرید و لفاف‏بندی(Encapsulation) همواره توسط طراحان تعديل مي‏شوند.بهعبارت ديگر،تعديل بين آن چه كه براي استفاده كننده مهم است و مخفي‏كردن نحوه انجام آن، هميشه يكي از مهم‏ترين تصميماتي است كه طراحان بايد اتخاذ نمايند. اما گاهي نحوه انجام تجريد به گونه‏اي مي‏شود كه تجريد اصطلاحاً نشتي پيدا مي‏كند. شايد بهتر است بگوييم كه لفاف‏بندي دچار نشتي مي‏شود. مثالهاي خيلي جالبي از اين موضوع را در نوشته‏هاي Joel Spolsky پيدا كردم كه توصيه مي‏كنم حتماً آنها را مطالعه نماييد.

نشتي تجريد،ما را به ياد ضرب‏المثل معروف “هر چه بگندد، نمكش مي‏زنند. واي به روزي كه بگندد نمك”مي‏اندازد.

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

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

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

عنوانمقاله: ضرورت بكارگيري مدل بومي SPCOM توسط پيمانكاران پروژ ه هاي فناوري اطلاعات

خلاصه مقاله:
در حال حاضر انجام پروژه هاي فناور ي اطلاعات و نرم افزار يكي از مهمترين دغدغه هاي هر كشور بوده، كه اين موضوع حركت به سوي كاربرد مدل ها و استانداردهاي مديريتي اين پروژه ها توسط پيمانكار ان را ضروري مي نمايد. در اين تحقيق اهميت و جايگاه كنترل و پايش در مديريت پروژه هاي مذكور مورد بررسي قرار گرفته و با معرفي اجمالي مدل بومي كنترل و پايش پروژه هاي نرم افزاري (SPCOM) -طراحي شده درمركز رشد دانشگاه تهران – به ضرورت كاربرد اين مدل مي پردازد. دلايل اين ضرورت در پنج سطح مختلف كه شامل انجام، مديريت،ا ستانداردسازي، مديريت كمي و بهينه سازي فرآيندهاي كنترل و پايش است، به تفصيل شرح داده شده و خصوصيات و موفقيت هاي پيمانكاران، در هر سطح اين مدل بيان گرديده است.

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

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

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

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

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

در مورد ابزارهاي كمك مهندسي يا CASE، مسئله نيز به همين منوال شده است. بلوغ ابزارها و ميزان راحتي كاربر بسيار مهم و اثرگذار در انتخاب آن است. سطح كمكي هم كه از ابزار مي‏خواهيد، به نوبه خود تأثيرگذار خواهد بود. Agile Modeling اصلي دارد با عنوان”استفاده از ساده‏ترين ابزار”. حتي استفاده از تخته سياه وسفيد بسیار می‏تواند مفید باشد.

آدرس زير ليستي از ابزارهايي كه UML را پشتيباني مي‏نمايند، نشان مي‏دهد. به نظر شما كدام یک ابزار مناسب‏تري است؟

http://www.objectsbydesign.com/tools/umltools_byDate.html

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

مهندسي نرم‏افزار تجربي يا Empirical Software Engineering شاخه‏اي از مهندسي نرم‏افزار است كه سعي دارد تا تجارب و نتايج عملي استفاده از كاربرد حوزه‏هاي مختلف مهندسي نرم‏افزار را سازماندهي و ارائه دهد.

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

آدرسهاي مفيد را براي مطالعه در زير آورده‏ام.

Empirical Software Engineering An International Journal

Empirical Software Engineering @ National ICT Australia

EASE Projct @ Japan