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

فکر می‏کنيد خلأ کداميک از نکات اشاره شده در آموزش فعلی مهندسی نرم‏افزار در کشورمان به چشم می‏خورد؟ منتظر پاسختان هستم (شايد بهتر باشد در اين مورد مباحثاتی داشته باشيم).

گزيده:

There are three types of people in this world: those who make things happen, those who watch things happen and those who wonder what happened.
– Mary Kay Ash

از هفته ديگر دوره Rational Unified Process در شرکت فراتر از دانش شروع می‏شود. يکی از موضوعاتی که می‏خواهم تأکيد بيشتری روی آن داشته باشم، CMMI است. اين امر بهانه‏ای شد تا در این مورد مطلبی بنويسم که در ادامه آمده است.

موضوع خيلی ساده است: «کيفيت سيستم يا محصول به شدت تحت تأثير فرآيندی است که برای توسعه و نگهداری آن به کار گرفته شده است». انستيتو مهندسی نرم¬افزار دانشگاه کارنگی ملون (CMU-SEI به اختصار SEI) طرح مدلهای بلوغ قابليتها را با اعتقاد به اين اصل شروع کرد. نتيجه آن چندین مدل بلوغ قابليت بود که از سال 1991 به بعد تهيه شدند مانند
• SW-CMM(Software Engineering CMM)
•Systems Engineering CMM (SE-CMM)
•People-CMM
نکته‏ی حائز اهميت آن است که پروژه‏ها تحت تأثير سه عامل (People, Process, Tools) هستند که SEI سعی کرد در حوزه‏های ديگر غير از فرآيند نيز مدلهايی ارائه دهد.
تنوع و تعدد مدلها (علاوه بر مدلهای CMM، مدلهای ديگری نيز در صنعت وجود داشت) باعث بروز مشکلاتی شد که طرح مدل بلوغ قابليتهای يکپارچه Capability Maturity Model Integrated یا به اختصار CMMI، برای حل مشکل مذکور پيشنهاد و از سال 1997 شروع شد واولين نسخه آن در سال 2000 انتشار پيدا کرد.
در حقيقت انگيزه SEI از توسعه CMMI ارائه مدل بلوغ قابليتی برای پوشش کارهای مرتبط با توسعه و نگهداری محصول و سرويس که شامل حوزه‏های زير بوده و قابليت گسترش به حوزه‏های جديد را نيز داشته باشد، بود.
-مهندسی سيستم(Systems engineering)
-مهندسی نرم‏افزار(Software engineering)
-توسعه محصول و فرآيند يکپارچه (Integrated product and process development)
-تأمين منابع (Supplier sourcing)
صرف نظر از اين که مدل ارائه شده از ديدگاه تخصصي چه ويژگی‏هايي دارد، چارچوبی را برای بهبود فرآيند توسعه و نگهداری محصول و سرويس در سازمانها ارائه می‏دهد. به عنوان مثال يکی از حوزه‏های فرآيندی که بايد برای بهبود سازمان در نظر گرفت مديريت پيکربندی (Configuration Management) است که مفيد است اگر تعريف آن را با هم مرور کنيم.
هدف:
هدف از مديريتپيکربندی، شناسايی، کنترل و مميزی محصولات کاری و نگهداری يکپارچگی آنها است.
از جمله محصولات کاری می‏توان به موارد زير اشاره کرد:
•طرحها (Plans)
•نيازمندی‏ها (Requirements)
•کدهای برنامه (Code)
•طراحی‏ها (Design)
برای روشن شدن کاربرد، اجازه بدهيد مثالی عرض کنم. فرض کنيد که قرار است نامه‏ای برای يکی از مشتريان ارسال شود. ابتدا نامه توسط کارشناس، تهيه، سپس توسط مدير عامل تأييد و سپس توسط مسئول دفتر مديريت، ويراستاری، ثبت و پرينت می‏گردد. واضح است که نامه بين مدير، کارشناس و مسئول دفترمديريت چندين بار جابه‏جا گرديده تا به نسخه نهايی تبديل گردد. از طرف ديگر پس از ارسال نبايد تغيير کند. آيا نسخه¬های بينابينی (نسخه‏هايی که بين مدير، کارشناس و مسئول دفتر جابه‏جا شده است)، بايد نگهداری گردد(شناسايی و تعيين اقلام پيکربندی). در صورتی که جواب مثبت است، چگونه اين کار را انجام دهيم؟ چه کسانی مسئول کار باشند؟ (فرآيند پيکربندی) چه کسانی حق دسترسی به نامه پس از ارسال يا نسخه‏های ميانی را داشته باشد (ضوابط فرآيند پيکربندی).
سئوال مهم‏تر اين است که آيا چارچوبی برای مشخص کردن نيازهای يک سازمان يا پروژه برای نگهداری اقلام تحت کنترل (اقلام پيکربندی) وجود دارد؟ آيا مرجعی بری کارهايی که بايد انجام دهيم تا اقلام پروژه تحت کنترل باشند، وجود دارد؟ يکی از جوابها و مراجع معتبر، CMMI و حوزه فرآيندی Configuration Management آن است.

توجه داشته باشيد کهCMMI تنها يک مدل است و نه راهکار اجرایی. بلکه بايد متناسب با هر سازمان، پياده‏سازی و عملياتی گردد.
پرواضح است که بيان تمامی ابعاد و کاربردهای CMMI در اينجا ميسر نيست، لذا توصيه می‏شود برای اطلاعات به آدرس http://www.sei.cmu.edu/cmmiمراجعه نماييد.

گزيده:
لغت نامه مهندسين در جلسات كارفرما
كاملا انجام شده يعنى: راجع به 10 درصد كار تنها برنامه ريزى شده !
تمام انتخاب اوليه به كنار گذاشته شد. يعنى: تنها فردى كه اين موضوع را مى فهميد از تيم خارج شده است!
روى چند انتخاب بطور همزمان در حال كار هستيم. يعنى: هنوز تصميم نگرفته ايم چه كنيم!

the OMG Systems Modeling Language (OMG SysML) is a general-purpose modeling language for systems engineering applications.SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems. These systems may include hardware, software, information, processes, personnel, and facilities.
The origins of the SysML initiative can be traced to a strategic decision by the International Council on Systems Engineering’s (INCOSE) Model Driven Systems Design workgroup in January 2001 to customize the Unified Modeling Language (UML) for systems engineering applications.
Currently it is common practice for systems engineers to use a wide range of modeling languages, tools and techniques on large systems projects. In a manner similar to how UML unified the modeling languages used in the software industry, SysML is intended to unify the diverse modeling languages currently used by systems engineers.
SysML reuses a subset of UML 2.1 and provides additional extensions needed to address the requirements in the UML for System Engineering.

گزیده:

Do you know that place between being asleep and awake, where you still remember your dreams? Thats where I’ll always love, that’s where I’ll always wait for you.
– Tinkerbell (Hook)

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

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

ماهنامه The Rational Edge در شماره اخير خود مقاله‏ای با عنوان What makes software so hard دارد که به نکات جالبی اشاره کرده است.
هر چند اين موضوع در مراجع مختلف و از ديدگاههای مختلف بررسی شده است، اما مرور آن خالی از لطف نيست.
در اين مقاله به مقايسه مهندسی نرم‏افزار با ساير حوزه‏های رايج مهندسی پرداخته است.
بخش جمع‏بندی و نتيجه‏گيری مقاله را در زير آورده‏ام.

Software is hard for a number of fundamental reasons:
* Software projects are design projects, not production projects.
* Because software is pure mindware, software development is more of an art or craft than a science or engineering discipline, making the “doing” disciplines of software development difficult to perform, monitor, and measure. Productivity differences between individuals are huge.
* Software lacks laws and first principles.
* Software lacks a measurable standard unit of work.
* Given software’s flexibility, the “supporting” disciplines of software projects — planning, estimation, prediction and observation — are quite difficult.
* Moore’s law makes the foundations of software ever changing — there’s no “permanent” platform to build on.
Even though it might be tempting to consider software engineering as “just another engineering discipline,” and thus jump to the conclusion that software can be developed using the same business, management, and engineering principles as traditional engineering, there are some unique characteristics that make software and software development not only special, but also more difficult to estimate and monitor than traditional engineering projects.
Software development, with its inherent characteristics, existing in a very dynamic world governed only by Moore’s law, will remain more art than a science for a long time to come. We can only hope to tackle the problems in software development by acknowledging that software is different, and understanding the consequences of these differences.
Any attempts to regard software development as just another form of traditional engineering will generally not deliver the desired results. Only by having a good understanding of what makes software different, can we start addressing the unique issues associated with software development. Iterative development, modeling, requirements management, and early-and-often stakeholder involvement are among the techniques available to software teams who recognize this critical difference and are looking for a new way forward.

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

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

گزیده:
آرزو داشتم روزي ناپلئون بناپارت شوم.ناپلئون را فردي با سينه و بازواني ستبر و عضلاني مجسم مي‏كردم كه شهرت و قدرتش نيرومند و عظيم است. بعد ها وقتي دريافتم كه او قامتي كوتاه و چاق داشته است به خود اميدوار شدم، چرا كه به آساني پذيرفتم كه تواناييهاي يك فرد به داشتن هيكل ورزيده، قد بلند و بازوي عضلاني نيست، بلكه تاثيري كه بر تاريخ به جاي مي گذارد اهميت دارد. هوندا

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

سماموس، تولدت مبارک.

گزیده:

I don’t regret the things I’ve done, but those I did not do.
– From Empire Records