دیروز برای شرکت در جلسه دفاع پروژه دو تن از دانشجويان رفته بودم دانشگاه.
نکته‏ بسیار مهم، موضوع تحقیق بود. “هدف از اين تحقيق در ابتدا آشنايی با مفاهيم مختلف نظريه بازی و سپس يافتن کاربرد اين مفاهيم در علوم مختلف و به ويژه در علم کامپيوتر می باشد. ” یکی از موضوعاتی که بدان پرداخته شده بود “کاربرد نظريه بازي در ترغيب کارکنان سازمان به اشتراک دانش” بود. هر چند ایده جای کار داشت، ولی در این سطح، بالاتر از حد انتظار بود.
مدلسازی اشتراک دانش در قالب مدل تئوری بازی و تحلیل و بررسی آن، یکی از کارهای تحقیقاتی قشنگ و در عین حال کاربردی این عزیزان بود.”تبادل دانش راهي براي به اشتراک گذاشتن دانش است. پردازش هاي مربوط به تبادل دانش را مي‏توان به عنوان بازيهاي بين عاملهاي خودخواه فرموله کرد. در اين بازيها هر عامل دانش را با ديگران به اشتراک مي‏گذارد، تنها براي اينکه سودمندي خود را افزايش دهد.”
کارهای دیگری از کاربردهای تئوری بازیها و طراحی و پیاده‏سازی بازی دوز در این قالب کارهای ابداعی دیگر این گروه بود که آنها هم جای تأمل داشتند.
به خانم دکتر تقی‏یاره؛ استاد گرامی‏ام؛ و به خانمها مريم رضوی و فرناز قوامی فر به خاطر انجام اين تحقيق تبریک عرض می‏کنم و امیدوارم بیش از پیش شاهد عناوین کاربردی در پروژه‏های دانشگاهی باشیم.
نکته: مطالب داخل “” از پایان‏نامه عزیزانبرداشته شده است.

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

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

گزیده: لغت نامه مهندسين در جلسات كارفرما
– تا چند دقيقه ديگر به اين موضوع مى رسيم. يعنى: فراموشش كنيد، الان به اندازه كافى مشكل داريم!
– ثابت شده كه …. يعنى: من فكر مى كنم كه …..!

Developing software costs money. Barry Boehm, in his classic work on software engineering economics, based upon 20 years of empirical evidence, concludes that the performance of a project can be predicted according to the following equation
Performance@ Complexity^Process * Team * Tools
Where
•PerformanceEffort or time
•ComplexityVolume of human-generated code
•ProcessMaturity of process and notation
•TeamSkill set, experience, and motivation
•ToolsSoftware process automation

From this equation, we can observe that the complexity of a system can either be amplified by a bad process or dampened by a good process and that the nature of a team and its tools are relatively equal contributors to the performance of a project.
Developing software costs money, and so for any sustainable business activity, any investment in software development must provide a good return on that investment. Thus, we might dream up suspicious uses of software that have no or marginal economic value (such as selling dog food over the Internet), but to do so will ultimately end in economic collapse. Alternatively, we might dream up meaningful uses of software, and to the degree we can develop that software efficiently and use that software as a strategic weapon in our business, and to do so will yield business success.

گزیده: (لغت نامه مهندسين در جلسات كارفرما)
– بقيه نتايج در گزارش بعدى ارائه مى شود… يعنى: بقيه نتايج را تا فشار نياوريد نخواهيم داد!
– بعلت اهميت تئورى و عملى اين موضوع… يعنى: به علت علاقه من به اين موضوع!
– حالا ما آماده ايم صحبتهاى شما را بشنويم… يعنى: شما هر چه مى خواهيد صحبت كنيد كه البته تاثيرى در كارى كه ما انجام خواهيم داد ندارد!

A further complication is the fact that, for industrial-strength software, there are typically a large number of stakeholders who shape the development process, most of whom are completely unimpressed by the underlying technology for technologies sake. These stakeholders will bring to the table a multitude of hidden and not-so-hidden economic, strategic, and political agendas that often warp the development process through the presence of competing concerns.

For software that matters, the requirements of a system will typically change during its development, not just because of reasons of technology churn or resilience, but also because the very existence of a software development project alters the rules of the problem.
Seeing early products such as design documents and prototypes and then using a system at each executable release are all forcing functions that lead users to better understand and articulate their real needs.

At the same time, this process helps developers master the problem domain, enabling them to ask better questions that illuminate the dark corners of a system’s desired behavior.

Because a large software system is a capital investment, we cannot afford to scrap an existing system every time its requirements change (or for that matter, to absorb considerable amounts fo scrap and rework).

Planned or not, large systems tend to evolve continuously over time, a condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, experience suggests that an inordinate percentage of software development resources are spent on software preservation.

گزیده:

Will you love me for the rest of my life?
No, I’ll love you for the rest of mine. – From Phenomenon

A further complication is the fact that, for industrial-strength software, there are typically a large number of stakeholders who shape the development process, most of whom are completely unimpressed by the underlying technology for technologies sake. These stakeholders will bring to the table a multitude of hidden and not-so-hidden economic, strategic, and political agendas that often warp the development process through the presence of competing concerns.

For software that matters, the requirements of a system will typically change during its development, not just because of reasons of technology churn or resilience, but also because the very existence of a software development project alters the rules of the problem.
Seeing early products such as design documents and prototypes and then using a system at each executable release are all forcing functions that lead users to better understand and articulate their real needs.

At the same time, this process helps developers master the problem domain, enabling them to ask better questions that illuminate the dark corners of a system’s desired behavior.

Because a large software system is a capital investment, we cannot afford to scrap an existing system every time its requirements change (or for that matter, to absorb considerable amounts fo scrap and rework).

Planned or not, large systems tend to evolve continuously over time, a condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, experience suggests that an inordinate percentage of software development resources are spent on software preservation.

گزیده:

Will you love me for the rest of my life?
No, I’ll love you for the rest of mine. – From Phenomenon

Consider the requirements for the avionics of a multi-engine aircraft, a cellular phone switching system, or an autonomous robot. The raw functionality of such systems is difficult enough to comprehend, but now add all of the (often implicit) nonfunctional requirements such as usability, survivability, and adaptability, indeed, all of the forces that shape a system. These unrestrained, potentially contradictory, external requirements are what amplify the arbitrary complexity ….
This external complexity usually springs from the “impedance mismatch” that exists between the users of a system and its developers: users generally find it very hard to give precise expression to their needs in a form that developers can understand. In extreme cases, users may have only the vaguest ideas of what they want in a software system.

Moreover, developers may not even know exactly the expectations of its user base, especially in the case of emerging, rapidly changing markets.

This is not so much the fault of either the users or the developers of a system; rather, it occurs because each group generally lacks expertise in the domain of the other. Users and developers have different perspectives on the nature of the problem and make different assumptions regarding the nature of the solution.

Actually, even if users had perfect knowledge of their needs, it is intrinsically difficult to communicate those requirements precisely and efficiently.

At one extreme, the development team may capture requirements in the form of large volumes of text, occasionally accompanied by a few drawings. Such documents are difficult to comprehend, are open to varying interpretations, and too often contain elements that are designs rather than essential requirements.

At the other extreme, there will be no stated requirements, only general visions and some specific stories, all retained in the heads of the developers. This may work for exploratory development or ultra-lightweight projects, but it is absolutely impossible to manage a development process against invisible requirements.

گزیده:

A life without love, is no life at all.
– “Ever After: A Cinderella Story”

The difficulty of design, therefore, lies in choosing which design and architectural patterns we should use to best balance the technical, economical, business, political, and emotional forces that swirl around every software-intensive system. To put it in terms of the laws of software, this general problem of design is probably NP-complete: there likely exists some absolutely optimal design for any given problem in context, but pragmatically, we have to settle for good enough. As we as an industry gain more experience with specific genres of problems, then we collectively begin to understand a set of design and architectural patterns that are good enough and that have proven themselves in practice for each particular domain. Thus, designing a new version of an old kind of system is easier, because we have some idea of how to break it into meaningful parts. However, designing a new version of a new kind of system with new kinds of forces is fundamentally hard, because we really don’t know the best way to break it into meaningful parts. The best we can do is to create a design based upon past experiences, plagiarize from parts that worked in similar kinds of situations, and iterate until we get it good enough.

Reference: The Limits of Software, Grady Booch, IBM Fellow, September 2004

گزيده:

“Let our advance worrying become advance thinking and planning.” –
Winston Churchill