همواره پاسخ به اين سؤال كه «برای آینده شغلی‌ام بايد روي چه مطالبي تمركز و برنامه‌ريزي كنم؟» با دشواري‌هاي زيادي همراه است.
يكي از روشهاي ساده رجوع به مراجع مورد اعتماد است. يكي از اين مراجع مهم، دانشگاههايي هستند كه در حوزه كاري‌ مورد نظر، رهبر و خط‌دهنده هستند.
براي مثال به برنامه سه ساله دوره Master of Science in Information Technology, Software Engineering Management در دانشگاه كارنگي ملون نگاهي بيندازيد.

گزيده:
روزها فكر من اينست و همه شب سخنم كه چرا غافل از احوال دل خويشتنم
از كجـــا آمــده‌ام آمدنم بهر چـه بـود به كـجا مي‌روم آخـر ننمايي وطنم
مانده‌ام سخت عجب كز جه سبب ساخت مرا يا چه بودست مراد وي از اين ساختنم

احمد هم رفت. هنوز هفت ماه از رفتن نوید نگذشته است که احمد عزیز هم رفت.
بازهم باید این جمله را تکرار کنم که «صرف نظر از دليل رفتن عزيزانمان، نتايج آن براي كشورمان و مهم‌تر از آن، براي خودمان، اسفبار است. »
خدا پشت و پناهشان.

گزيده:
موطن آدمی را بر هیچ نقشه‌ای نشانی نیست
موطن آدمی تنها در قلب کسانی است که دوستش می‌دارند.

ماركوت بيگل – برگردان زنده‌ياد شاملو

گزارشي با نام CMMI or Agile: Why Not Embrace Both مطالعه كردم كه بسيار جالب بود. پبشنهاد مي‌كنم اين گزارش را با دقت مطالعه كنيد. اگر هم موضوع گزارش، با علائق شما مرتبط نيست، پيشنهاد بعدي‌ام اين است كه بخش دوم آن با عنوان Origins from Two Extremes را مطالعه نماييد كه بررسي تاريخجه روشهاي چابك و CMMI مي‌پردازد.

Table of Contents
– Problem Definition
– Origins from Two Extremes
– Factors that Affect Perception
– The Truth About CMMI
– The Truth About Agile
– There Is Value in Both Paradigms
– Problems Not Solved by CMMI nor Agile
– Conclusion
– Epilogue: A Call to Action
– CMMI and Agile Paradigm Comparison

Quote😐
It is a tremendous privilege to be a software professional, it is also a tremendous responsibility.
Grady Booch

I suggest you read this article in JOT.
The objectives of this paper are to clarify the terminology of software requirement models by suggesting a more consistent usage, to describe the different versions of requirement models, and to illustrate how to effectively address requirements analysis for large scale systems.

Quote:
Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.
–Suzanne and James Robertson

In the wake of the recent PDC and TechEd developer events, Microsoft has decided to put some of its key executives out on the road to explain the innovations that Visual Studio 2010 and .NET 4.0 have in store.
Show related articles

Microsoft is promoting the next version of its Visual Studio toolset, code-named Rosario, as offering new levels of analysis of the application development process.
Reference: zdnet.co.uk

Quote:
A designer is an emerging synthesis of artist, inventor, mechanic, objective economist and evolutionary strategist. —R. Buckminster Fuller

خانم Rebecca Wirfs-brock نظرش را در مورد بازنگري معماري در مصاحبه‌اي با راديوي مهندسي نرم‌افزار ارائه كرده است. مصاحبه را مي‌توانيد در اينجا بشنويد.
جملات زير از ايشان نقل شده است كه نگراني‌اش را در مورد طراحي و كيفيت آن بيان نموده‌اند.

These days, complex IT systems are rarely understood by a single engineer or architect. Teams come together to create complex software systems. Technical challenges can be enormous and the “tricky bits” involve the subtle interplay of business and technical design decisions. The focus is on achieving overall business objectives, not the optimal design of a single component. Yet poorly designed interfaces, sluggishly performing services, or crappily constructed components can cause enormous grief. Design still matters.

Quote:
Software development has been, is, and will remain fundamentally hard.
Grady Booch

• Big systems are hard to get right. Thinking about “architecture stuff” up front is necessary for success.
• Architecture is the bearer of quality, but reasoning about architecture is actually reasoning about the potential of a system.
• Performance and flexibility really do trade off against each other.
• Reprioritizing architectural qualities is extremely risky.
• Don’t forget “saleability” and “marketecture.” They can help you sell a system to upper management before it is built, even if they offend a “pure” architecture sensibility.
• Autonomy of organizations and systems is paramount, and this autonomy happens to be the foundational principle of service-oriented architecture.
• If you don’t know where you’re going, you’re not going to get there—regardless of how good your map is.
• Technology doesn’t matter. What does matter are people, the process, and the consistency of practice.
• Architecture validation is critical but hard to institutionalize—even in a process-oriented organization.
• The deepest problems in IT are still communication and understanding.
• Don’t let “pragmatism” become a disguise for shortsightedness.

Reference:Lessons Learned about Software Architecture @ SEI
Quote:
“Architecture is not a set of PowerPoint slides, It’s the bridge between the business goals and the way a system operates.” Michael Gagliardi