خوشبختي ما در سه جمله است:
تجربه از ديروز، استفاده از امروز، اميد به فردا

ولي ما با سه جمله ديگر زندگي‌مان را تباه مي‌کنيم:
حسرت ديروز، اتلاف امروز، ترس از فردا
دكتر علی شریعتی

مرجع: از بین نامه‌هاي حميد

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

XP pretty much banned use cases, replacing them with the similar sounding “user stories” (see A user story is to a use case as a gazelle is to a gazebo}, and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems:

1. User stories and backlog items don’t give the designers a context to work from
2. User stories and backlog items don’t give the project team any sense of “completeness” –
3. Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work

Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. As not-Einstein said: “Make things as simple as possible, but no simpler.” (The attribution to Einstein has been debunked, it seems.) In particular, use cases fix those three problems.
Here 5 reasons why I still write use cases:

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: “What are we supposed to do in this case?” (which is normally answered by, “I don’t know, I’ve never thought about that case.”) In other words, it is a thinking / documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

Reference: alistair.accountsupport.com
Alistair is author of Patterns for Effective Use Cases and Writing Effective Use Cases books

Quote:
“There is no reason for any individual to have a computer in his home.”
(Ken Olson, President, Digital Equipment Corporation, 1977)

Pattern-based web applications have become popular since they promote reusability and consistency. In few cases, patterns do not produce the desired effect because of lack of experience in applying them. This situation forces one to think of a suitable re-engineering solution for such applications. The objectives of the paper are three fold. It provides a survey of different pattern-based web applications that will be useful for the application designers. It highlights some of the web applications where patterns have been inappropriately handled. A few re-engineering initiatives for such cases are also analyzed.

Reference: Journal of Object Technology
Quote:
“There’s an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone.” Bjarne Stroustrup

خيلي ساده اتفاق افتاد.
داشتم مصاحبه گريدي بوچ با يكي از رسانه‌ها را مي‌خواندم. از وي پرسيده شده بود كه قهرمانانش چه كساني هستند. از چند نفر نام برده است كه انسانهاي تأثيرگذار و البته مسن‌تر از وي بودند. يك نام در آنها وجود داشت كه در سن 48 سالگي از دنيا رفته بود. استاد دانشگاه كارنگي ملون كه در سال 2008 به دليل عارضه‌ي سرطان از دنيا رفت. كارهايي كه انجام داده بود از جمله‌ي پروژه‌ي آليس را به دقت بررسي كردم. اما چرا بايد اين شخص مورد ارادت شخصي چون گريدي بوچ باشد.
به ناچار به جستجويم ادامه دادم. حالا ديگر موضوع كاملاً از كارِ ساده‌ي مطالعه‌ي كوتاه وبلاگ‌هاي علمي و فني به جستجويي براي حل معمايي تبديل شده بود. مطلبي نظرم را جلب كرد. «آخرين كنفرانس».
«آخرين كنفرانس» در تاريخ 18 سپتامبر 2007 توسط وي برگزار شده بود كه عنوان كنفرانس «واقعاً به روياهاي بچگي‌تان دست پيدا كنيد» با حضور حدود 400 نفر از اساتيد، دانشجويان و همسرش، حدود 6 ماه قبل از درگذشتش. در اكتبر همان سال در برنامه‌ي اپرا حاضر شد و در اين‌باره مجدداً سخن گفت. به همراه جفري زاسلو، سخنراني‌اش را به صورت كتابي منتشر كرد كه يكي از پرفروشترين كتابها در اكتبر 2008 به نقل از نيويورك تايمز شد. كتابي كه در اولين چاپ به تيراژ 400 هزار نسخه رسيد و به 46 زبان دنيا ترجمه شد.

ديگر صبرم لبريز شد به سراغ فيلم كنفرانس رفتم. با دقت به سخنراني گوش كردم. چند دقيقه‌اي اول را ديدم اما به دليل سرعت كم اينترنت، نتوانستم ادامه دهم. همان صحنه‌ي اول سخنراني كافي بود. همان لحظه نامه‌اي به آقا رضا زدم و خواهش كردم كه فيلم را برايم دانلود كند. پس از دريافت فيلم از ايشان و به محض رسيدن به خانه، شروع به تماشايش كردم. خداي من.
در اين سخنراني، او در عين خنداندنتان، نكاتي را به شما ياد مي‌دهد و يا نكاتي را به يادتان خواهد آورد، كه ديگر از ياد نخواهيد بود. دنبال روياهاي كودكي بودن. باوركردني نيست، شخصي در آن وضعيت چگونه اين همه روحيه دارد. هر بخش از سخنراني‌اش درسي است براي آينده، براي لذت بردن از زندگي.
بعد از آن كتابش را از جايي پيدا كردم و شروع كردم به خواندنش. كتابي كه پر است از نگاه جذاب وي به زندگي و به روياهاي كودكي.
در آخر، سخنراني به اين شكل پايان مي‌يابد:«اين سخنراني براي شما نبود. اين سخنراني براي ديلون، لوگان و چلو، بچه‌‌هايم بود».
اين مرد بزرگ، كسي نبود جز Randy Pausch.

http://en.wikipedia.org/wiki/Randy_Pausch

http://www.thelastlecture.com/

http://en.wikipedia.org/wiki/The_Last_Lecture

http://www.amazon.com/Last-Lecture-Randy-Pausch

Quote:
With thanks to my parents who allowed me to dream, and with hopes for the dreams my children will have. Randy Pausch

More than twelve years have passed since UML, the Unified Modeling Language, became a standard.
At the beginning of the 1990s there were 26 published methods on object-orientation, most methods with its own notation. It was to address at least the notation problem that UML was conceived.
UML also found a number of detractors. It was criticized by the academic world.The great David Parnas called UML the “Undefined Modeling Language”, a strongly exaggerated but not unfounded criticism. The criticism stung.
The original leaders of the agile movement were also strongly against modeling.For them it was the “Unnecessary Modeling Language” – they said “no modeling – just code”.
Microsoft, reticent to do anything that might strengthen the competition, also did not initially support UML. Instead they were moving in a different direction based on domain-specific languages.

Now we find the pendulum swinging back. There are a number of good and easy to use tools. The criticism from the academic community has quieted. Agility has been embraced by large companies who see value in both “smart” modeling combined with an agile approach. People use UML though skepticism about the tools remains; many people work with sketches on white boards and use tools sparingly. Microsoft found that domain-specific languages did not replace the role for UML and that customers actually wanted to use UML. Today Microsoft is a strong supporter of UML.

Today the world looks upon UML with a more balanced perspective. UML is not the ”silver bullet” it was sold as ten years ago. Nor is it as bad as academicians, agilistas and competitors claimed five years ago. Used appropriately it is a practical tool for raising the level of abstraction on software from the level of code to the level of the overall system. And its use increases again, as it should, but now with more common sense.

Still, UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call the “Essential” UML. We must make UML

Reference: Ivar Jacobson

Quote:
There are just two kinds of languages: the ones everybody complains about and the ones nobody uses. Bjarne Stroustrup

Grady Booch is an IBM Fellow and one of the co-creators of UML. In this talk, he discusses the complex matrix of decisions and processes, both intentional and unintentional, that lead to the software designs and architectures upon which we increasingly rely in everyday life. This is a version of a talk originally given to the British Computer Society in honor of Alan Turing.
http://espanol.video.yahoo.com/watch/577305/2839970

Quote:
“Hardware: The parts of a computer system that can be kicked.” (Jeff Pesis)
Reference