ایا میتوانید این عبارت را بخوانید. اگر این طور است، پس میتوان همواره این گونه هم نوشت؟
شاد باشید و تندرست.
گزیده:
چشمها را باید شست، طور دیگر باید دید.
فارسی
در اهمیت نرمافزار
دوستی دارم که زمانی به من گفت: “اگر زمانی نرمافزارهای ساخت ما کار نکرد و مشتریان با چوب و چماق افتادند دنبال ما، آن وقت میفهمم که نرمافزار در ایران، دیگر کالای لوکس نیست”.
خبرهای رسانهها و بحثهایی که در محافل غیرنرمافزاری درباره سیستمهای نرمافزاری میشود، شاید معیاری باشد برای افزایش اهمیت نرمافزار در ایران.
خبرهای زیر و یادداشتهای خوانندگان را بخوانید. برایم جالب و آموزنده بود.
http://www.donya-e-eqtesad.com/Default_view.asp?@=282774
http://ebinews.com/news/9583
http://ebinews.ir/news/19077/
http://ebinews.com/news/19638/
http://www.donya-e-eqtesad.com/Default_view.asp?@=285510
گزیده:
اينكه امروز كه هستيم، پيامد گزينش ديروز ما است. فردا هم همان خواهيم شد كه امروز برمي گزينيم. جان ماكسول
اس.جی.
تحلیل و طراحی شیءگرا
چند وقت پیش دوستی، پرسش زیر را مطرح کرده بود:
«میخوام تجزیه و تحلیل شیءگرا کار کنم. به نظر شما چه کتابهایی در این زمینه مفید هستد و به چه ترتیبی اونها رو مطالعه کنم»
از خوانندگان وبلاگ خواهش کردم که لطف کنند و در صورت امکان، راهنمایی فرمایند. نتایج را در اینجا میتوانید مطالعه کنید.
فرض بر این قرار گرفت که ایشان به دنبال تحلیل و طراحی شیءگرا هستند. به خود فرصتی دادم تا راجع به این پرسش فکر کنم. چون فرصت نکردم، تصمیم گرفتم که به صورت آنی مواردی که به نظرم میرسد، در اینجا بنویسم. امیدوارم مفید باشد.
توصیهها:
یک سال در یک تیم نصب، استقرار و پشتیبانی نرمافزاری کار کنید که کاربر از آن ناراضی است. این موضوع به شما کمک میکند که:
– ببینید کاربر چرا ناراضی است
– و چرا گاهی درخواستهای جدید کاربر نمیتواند در سیستم اعمال شود
– و چرا تیم پشتیبانی قادر به اعمال درخواستها در زمان مورد نظر کاربر نیست
– و نرمافزار چه خصوصیاتی باید داشته باشد تا انجام امور فوق سادهتر باشد
در این مدت بسیار کنجکاو باشید.
اگر در این مورد مسئولیت آزمون و پذیرش محصول نیز با شما بود که عالی است، وگر نه توصیه میکنم مدتی برای آزمایش یک نرمافزار وقت بگذارید. این کار به شما یاد میدهد که «یک پلیس خوب ابتدا باید دزد خوبی باشد(به نقل از یک فیلم قدیمی)» یعنی همیشه موقع طراحی و پیادهسازی به این بیندیشید که کجای طراحی و کد شما درز دارد.
سه سال وقت بگذارید تا برنامهنویس فوقالعادهای شوید. ابتدا تعریف کنید که کد دوستداشتنی شما چگونه است و برنامهنویس مورد علاقه شما چه کسی میتواند باشد، سپس با یک برنامهریزی به دنبال کسب شایستگیها و مهارتهای لازم باشید. یادتان باشد این موضوع را در سطح فارغ از زبان تعریف کنید. بهترین طراحانی که میشناسم، برنامهنویسان فوقالعادهایاند.
سعی کنید همزمان در دو فضای رقیب و متفاوت حرکت کنید، یکی عمیق و دیگری کلان. مثلاً حوزه راهحلهای دات نت و جاوا. این کار به شما امکان میدهد:
– تا متعصب نشوید
– و دیگر این که یاد بگیرید که چگونه توسط یکی، دیگری را یاد بگیرید
– و مهمتر از همه، تفاوتها و شباهتها به شما امکان یادگیری عمیق و طراحیهای بهتری را خواهد داد.
قلمرو مسأله (domain) – مثلاً حوزه مالی – را بیاموزید. اگر در شرکتی مشغول به کارید یا قصد خروج از شرکتی را دارید، به یاد داشته باشید که حضور مستمر در یک قلمرو مسأله بسیار مهم است. چرا؟ بهترین طراحیها وقتی صورت میگیرد که طراح درکی عمیق از مسأله داشته باشد. به عنوان مثال مهمترین دستاوردها در استفاده مجدد، در قلمرو مسأله است نه در حوزه تکنولوژی. اقلام استفاده مجدد در تیمها را که مینگرید شامل رخدادنگاری، امنیت، … هستند؛ یعنی همه چیز غیر از قلمرو مسأله. متأسفانه عزیزان طراح ما بر این باورند که باید در اتاق خود بنشینند تا تحلیلگران یا کاربران به آنها یاد دهند که قلمرو مسأله چیست:
– تحلیلگر یا کاربر دغدغههای شما را نمیشناسد که به شما منتقل کند
– دیگر این که این نکات با ده یا صد پرسش قابل انتقال نیست و موضوعی است تدریجی.
خود خواهید یافت که چه زمانی، شرایط تغییر قلمرو مسأله فرا رسیده است.
در کنار کسانی کار کنید که آنها را به عنوان طراح و برنامهنویسِ فوقالعاده میشناسند و قبول دارند. نگاه، تفکر و روششان را بیاموزید. بخشی از یادگیری، یادگیری استاد-شاگردی است. این بخش را جدی بگیرید. اگر این سعادت را پیدا کردید، آموختههایتان را یادداشت و برایم بفرستید تا من نیز بیاموزم.
تکنولوژیزده (برای شوخی آنها را تکنوکرات مینامم) نباشید. تکنولوژی را یاد بگیرید اما برای یادگیری آن، پروژه دیگران را که هزینهاش با شما نیست، خراب نکنید. هزینه، زمان، نیروی انسانی تولید و نیروی انسانی پشتیبان سیستم و چندین خصیصه غیرفنی در اتخاذ تصمیمات بسیار مؤثرند، آنها را لمس کنید. تصمیمگیرنده فنی لازم است که احساس وظیفه سازمانی و به دور از علایق شخصی کند. برای هر راه حلی، پیش خود مقادیر عددی خصوصیات بالا را محاسبه کنید.
در عین حال که معماری نرمافزار، الگوها، طراحی و تحلیل و … را یاد میگیرید، همواره به یاد داشته باشید که آنها ساخته ذهن یک انسان دیگر است و ممکن است لزوماً درست نباشد. تابوها را بشکنید و دیگر گونه فکر کنید. یادگیری آنها خیلی اوقات منجر به تخریب خلاقیت شما خواهد شد. اگر اصول را بدانید، راهحلهای طراحی شما، بیشک یکی از الگوهای طراحی خواهد بود. معماری، الگوها و … هدف نیستند، ابزار هستند. اما یادتان باشد که چرخ را دوباره اختراع نکنید. اشکالی که امروزه دیده میشود چیزی شبیه افراط و تفریط است. بعضی هیچ نمیدانند و نفی میکنند، و بعضیها میدانند و غرق این ابزارها شدهاند. تعادل بهترین است. شناسایی نقطه تعادل را خواهی آموخت.
اصول را به درستی بیاموزید. عزیزان بسیاری را میشناسم که آخرین تکنولوژیها را تجربه کردهاند، اما مفاهیم سادهای چون encapsulation برایشان غریبه است یا در حد تعاریف کتاب یا مثالهای ساده و ابتدایی میدانند.
جمعی از دوستان همفکر را پیدا کنید. دو هفته یک بار یا ماهی یک بار با هم قرار بگذارید. تجربه و یادگیریهایتان را برای هم تعریف کنید. کد نوشته شده یا طراحی انجام شده را بازنگری کنید و از آن بیاموزید. از جلسه سوم به بعد، خوشحال میشوم اگر از بنده هم دعوت کنید که در جلسات شما حاضر شوم.
هر وقت خواستی نکتهای در تحلیل و طراحی یاد بگیری، ابتدا چراییاش را بیاموز و بعد تاریخچه و منشأاش را. این موضوع به شما کمک میکند، با حفظ چرایی، چگونگی را با شرایط تطابق دهید.
نمونه خوب زیاد ببینید. طراحیها و کدهای اوپن سورسهای با کیفیت را بخوانید. کد همکاران کاربلدتان را زیاد بخوانید.
هر چند وقت یک بار، طراحیهای قدیمی یا کدهای قبلیتان را مرور کنید. ببینید اگر آن را دوباره انجام دهید، کجاهایش تغییر خواهد کرد. این تغییر از کجا ناشی شده است. اتفاقی بوده یا برنامهریزی شده.
تصمیمگیری، انتخاب، ارتباط و مشارکت و به طور کلی مهارتهایی عمومی تأثیرگذار بر کارتان را بیاموزید. به استقبال نقدشدن بروید.
زبان انگلیسیتان را قوی کنید. اگر بتوانید همان طور که متن انگلیسی مینویسید، کد بنویسید. یا همان طور که موقع صحبت کردن، فکر میکنید، طراحی انجام دهید، کار تمام است. در آینده کافی است روش نوشتن و حرف زدنتان را عوض کنید، همه نرمافزارتان عوض میشود.
تفکر در یک نگرش مثل شیءگرایی کم کم ذهن شما تحت تأثیر قرار میدهد. سعی کنید پارادایمهای دیگر را نیز گاهی تجربه کنید تا ذهن شما را فریب ندهد.
هر وقت احساس کردید که از تحلیل و طراحی لذت نمیبرید، به مرخصی بروید یا کارتان را عوض کنید.
جایی که هر چند وقت یک بار بتوانی آن را بخوانید، این جمله را قرار دهید: هدف، مؤفقیت پروژه است!
و در آخر: کتاب بخوانید.
ببخشید که طولانی شد.
گزیده:
پاداشهايي كه در زندگي ميگيريد بستگي به اين دارد كه چه كاري ميكنيد، چقدر خوب آن را انجام ميدهيد و چقدر مشكل است كه بتوان كسي را جايگزين شما كرد. برايان تريسي
مرجع: اسجی
رویای شخصی
بالاخره پس از سالها مؤفق شدم کاری که بسیار دوستش میدارم و به شکلی مسئولیت شخصیام میپنداشتم را به انجام برسانم.
حدود دو سال پیش، بخشی از این ایده را با عزیزانی مطرح کردم و متأسفانه اجرای آن برایشان میسر نبود. در این مدت هم، مشغلههای زندگی و کار فرصت سوزی کرد. پس از این مدت طولانی، شرایطی مهیا شد تا دوباره برای انجامش اقدام کنم و خوشبختانه این بار مؤفق شدم.
اما این کار چه بود:
یکی از اشکالات دورههای آموزش مهارتهای تخصصی در حوزه نرمافزار این است که متقاضی آموزش با مجموعهای از دورهها مواجه است. هر متقاضی مجموعهای از دورهها را برای آموزش انتخاب میکند که ارزیابی از اثربخشی مجموع دورهها قابل حصول نیست. این معضل شاید یکی از نقاط ضعف بسیاری از دورهها باشد.
یکی از کارهایی که همواره علاقهمند به انجام آن بودم، طراحی دورههایی بود که نیازهای مهارتی و دانش یک نقش (role) مشخص را در تیمهای تولید نرمافزار پوشش دهد. مبتنی بر دانستهها، تجربههای کاری و آموزشی و نیز مشورت دوستان متخصص، این دورهها را برای چندین نقش طراحی کردم، اما با توجه به فرصت فعلی، در حال حاضر تنها یکی از آنها را برای اجرا انتخاب کردهآم: نقش تحلیلگر سیستم.
این تغییر روش امکان آن را فراهم ساخت تا مطالبی را که مدتها و بارها شرکتکنندگان درخواست آن را داشتند و خود نیز مشتاق آن بودم ولی به همان دلیلی که عرض شد، در دورهها گنجانده نشده بود، به مطالب اضافه شود. از جمله این موارد میتوان به مدلسازی کسبوکار، روشهای تحلیل در مدلهای تکراری، مدل شایستگی تحلیلگران(ویژگیهای فردی، دانش و مهارت) اشاره کرد.
یکی بودن عنوان دوره با عنوان کتاب، تهدید جدی است چرا که مخاطب تصور خواهد کرد که مطالب دوره همان مطالب کتاب است. با علم به این تهدید، این عنوان انتخاب شد.
با توجه به تجارب گذشته، نسبت به نتایج برگزاری دوره بسیار خوشبین هستم. در زیر سرفصل مطالب را آوردهام. مطالب بیشتر درباره دوره را میتوانید در اینجا مشاهده فرمایید.
گزیده:
سفر راستين براي كشف كردن، رفتن به مكانهاي تازه نيست، بلكه يافتن نگاهي تازه است. ارسل پروست
Introduction
Requirements: An Introduction
The Role of Requirements in Software Development
Definition, Classification and Levels of Requirements
Analyze the Problem
Problem and Problem Analysis
Problem Analysis in Software Development
Case Study
Understand Stakeholder Needs
Understand Needs
Identify Features in Software System
Using Business Modeling for Needs and Features Identifications
The Importance of Vision
The Role of Business Rules in Software Development
Elicit and Document the Business Rules
Case Study
Define the System
Use Case Model: An Introduction
Develop Use Case Model: Step by Step
Using Business Modeling for Use Case Development
Using UML for Use Case Model
System Wide Requirements
Workshop
Case Study
Object Oriented Analysis- Domain Modeling
Defining the Analysis Model and Its Role in Software Process
Analysis Model Development Approaches
Techniques for Develop the Analysis Model
Workshop
Case Study
Supplementary Topics
Requirements Elicitation Techniques
Requirements in Iterative Process Model
System Analyst Competency Model
کد دوستداشتنی
در دورههای آموزشی از شرکتکنندگان میخواهم تا از دید خود بگویند چگونه کدی را دوست دارند و بدان عشق میورزند. در ابتدا خصایص کد مورد علاقه خود را توضیح میدهند و بعد تکه کدی را (از کدهای خود یا دیگران) انتخاب و خصایص را در آن جستوجو میکنند و در صورت یافته نشدن، کد را به شکلی که دوستداشتنی شود، تغییر میدهند یا توضیح میدهند که چگونه این کار انجام شود.
این گونه کدها را «کد دوستداشتنی» میخوانیم.
توصیه میشود که در تیمهای کاری یا دانشگاهی این ایده را پیاده کنید. خوشحال خواهم شد از نتایج آن آگاه شوم.
پرسش: شما چگونه کدی را دوست میدارید؟
گزیده:
برای زیستن دو قلب لازم است، قلبی که دوست بدارد، قلبی که دوستش بدارند.
احمد شاملو
درخواست راهنمایی از خوانندگان محترم
یکی از خوانندگان عزیز وبلاگ، خانم یا آقای یزدانجو یادداشتی گذاشته بودند که در زیر آوردهام:
«من به تازگی از دانشگاه فارغ التحصیل شدم و به آنالیز وطراحی علاقه مندم. لطفا منو راهنمایی کنید و منابع پیشنهادی تون رو در این زمینه معرفی کنید. ممنون میشم از تجربیات شما استفاده متن.
می خوام تجزیه و تحلیل شی گرا کار کنم. به نظر شما چه کتاب هایی در این زمینه مفید هستد و به چه ترتیبی اونها رو مطالعه کنم»
با وجود آن که پرسش بسیار جالبی پرسیدهاند، اما پاسخ دادن به آن کار دشواری است. هر چند بارها به این پرسش پاسخ دادهام، اما قصد دارم پرسش ایشان را به گونه دیگری پاسخ گویم که نیازمند فرصت و تمرکز است.
برای این که پاسخ این دوست گرامی را بیپاسخ نگذاشته باشم، از خوانندگان عزیز درخواست میکنم در صورتی که میتوانند از تجربیات خود، آقا/خانم یزدانجو و بنده را بهرهمند نمایند.
پیشاپیش از همگی شما سپاسگزارم
گزیده:
Three sentences for getting success: Know moe than other, Work more than other, Expect less than other; William Shakespeare
IBM Chief Scientist to Launch TV Series on Computing
Grady Booch, a chief scientist at IBM Research, and his wife Jan have launched a project to tell the story of computing in an 11-episode TV series similar to Carl Sagan’s Cosmos.
I need your help in telling a story, the story of the technology that has changed humanity: computing.
Why Is Computing Important?
Because the story of computing is the story of humanity.
Computing is a story of ambition, passion, invention, creativity, vision, avarice, and serendipity, powered by a refusal to accept the limits of our bodies and our minds. From the abacus to the iPad, from Gutenberg to Google, from Enigma to GPS, we have created computers to count the uncountable, remember beyond our own experiences, and see the invisible as well as the unforeseeable. To explore computing is the 21st Century equivalent of Cousteau exploring the sea, of Hughes exploring modern art, and of Burns exploring the American experience through the Civil War, baseball, and jazz.
In just one or two generations – an imperceptible time in the timeless sweep of the universe – we have created a technology that has the power to extend us, to transform us, to define us, perhaps even to destroy us.
Who Are We?
I am Grady Booch an IBM Fellow, co-creator of UML and Object Oriented Programming – and general braniac and onscreen presenter/host. I know that I cannot do a project this big by myself and so I have gathered around me other people smarter and more creative than me. My wife Jan is a theologian and psychotherapist; she is my co-creator and advisor whose job is to keep it real. Seth Friedman is an award-winning writer and creative director; he is our co-creator and scriptwriter.
Quote:
The amateur software engineer is always in search of magic. Grady Booch
