My husband and I are both in an Internet business, but he’s the one who truly lives, eats and breathes computers. I finally realized how bad it had gotten when I was scratching his back one day. “No, not there,” he directed. “Scroll down.”

Ref: readersdigest.com

گزيده:
خنده بر هر درد بي‌درمان دواست.

A list of top N risks, especially during risk survey, is helpful in getting a
feel of the risk environment. Here are a few examples:
Brian A. Will’s List
1. Creeping requirements
2. Requirements or developer gold plating
3. Low quality of released software
4. Unachievable schedule
5. Unstable tools causing schedule delay
6. High turnover
7. Friction between developers and customers
8. Unproductive office space

Dr. Barry W. Boehm’s List
1. Personnel shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong functions and properties
4. Developing the wrong user interface
5. Gold plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer science capabilities

Chester Simmons’s List
1. Program risks
2. Schedule risks
3. Cost risks
4. Technical risks
5. Supportability
6. Development risks
7. Communications
8. Engineering database
9. Program plan
10. Concurrent engineering trick

Reference: Applied Software Risk Management, Ravindranath Pandian, 2006

گزیده:

Modeling Principle:
Models are not right or wrong; they are more or less useful.
Martin Fowler, Analysis Pattern

آفرينش اشياء(Object Creation) به عنوان يكي از موضوعات مهم در طراحي به شكلي با موضوع جذاب معكوس‌سازي كنترل و تزريق وابستگي مرتبط است. مناسب ديدم برخي منابع مفيدي را كه در اين زمنيه وجود دارد، در اينجا ذكر كنم.

Inversion of control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries.

Dependency injection (DI) in Computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency.

References:
– Inversion of control (IoC)
– Dependency injection (DI)
– Inversion of Control Containers and the Dependency Injection pattern
– Java: Spring Framework
– .NET: Unity – Dependency Injection and Inversion of Control Container
– .NET: The Unity Application Block

گزيده:

Patterns are a starting point, not a destination. Martin Fowler, Analysis Pattern

برگرفته از : کسب و کار نرم‌افزار

تا به حال لیست‌های متفاوتی از بهترین و تاثیرگذارترین کتاب‌های کاربردی مهندسی نرم‌افزار منتشر شده است. آنها با تفاوت‌هایی ناچیز، دارای فهرستی مشترک هستند یعنی اگر هرکدام ۱۰۰ کتاب را فهرست کنند دست کم ۹۰ مورد بین همه آنها مشترک است، البته تفاوت‌هایی هم در رتبه‌هایی که به کتاب‌ها داده می‌شود وجود دارد.
چند روز پیش دوباره به چنین لیستی برخوردم و پیوند دادن به آن را خالی از لطف ندیدم.
پیش از ادامه یادآور می‌شوم که خود بر آنم که یک مهندس کامپیوتر خوب، باید انگلیسی را بسیار خوب بداند و کتاب‌ها را به زبان اصلی بخواند. اما نکته‌ی تاسف باری که باز ذهن من را به خود مشغول کرد این بود که تقریبا هیچکدام به فارسی برگردانده نشده‌اند (دست‌کم تا آنجا که من می‌دانم) بسیاری از این کتاب‌ها کلاسیک هستند و با گذشت سال‌ها از انتشارشان هنوز بسیار پرکاربرد هستند.
با وجود اینکه بازار ترجمه کتاب‌های کامپیوتری در ایران داغ است (گذشته از این نکته که بسیاری از آنها دارای ترجمه‌هایی با سطح بسیار پایین هستند)، هنوز این کتاب های بسیار اساسی و مورد نیاز صنعت کامپیوتر ترجمه نشده‌اند. امیدوارم مترجمان خوب این حیطه کمی دست از ترجمه کتاب‌های سطحی و تکراری دست برداشته و به سراغ این کتاب ها بروند.
این لیست را در اینجا می توانید مطالعه کنید.

گزيده:
مصمم شويد كه كارى بايد صورت گيرد، سپس راه انجام آن را خواهيد يافت . آبراهام لينكلن

فصل چهارم از كتاب Object-Oriented Analysis and Design with Applications نوشته گريدي بوچ، به بررسي يكي از سخت‌ترين موضوعات تفكر بشري كه تأثير شگرفي بر مدلسازي و طراحي دارد، پرداخته است. ضمن دعوت براي مطالعه اين كتاب،‌ ترجمه و خلاصه اين فصل را كه آقاي مهندس آزادكيان زحمت آن را تقبل نموده‌اند، در زير آمده است. از آقاي مهندس آزادكيان نيز سپاسگذارم كه اين متن را در اختيارم قرار دادند.

طبقه‌بندي (classification) توانايي مرتب‌سازي دانش ما نسبت به اشياء دامنه مساله است. در طراحي شي‌گراء، شناخت يكنواخت اشياء باعث مي‌شود كه وجوه اشتراك بين تجريدها و مكانيزمهاي كليدي، نمايان گشته و در نهايت برنامه‌‌‌هاي نرم افزاري جمع و جور و با معماري ساده‌تر داشته باشيم. اما مشكل اينجاست كه يك راهنماي سريع و سهل‌الاستفاده براي اين موضوع وجود ندارد. به عبارت ديگر تشخيص اشياء و دسته‌بندي آنها در غالب كلاسها يك دانش تجربي است.
اهميت طبقه‌بندي از آنجا ناشي مي‌شود كه به ما كمك مي‌كند تا سلسله مراتب ارتباط بين اشياء را شناسايي كنيم. همچنين با استفاده از طبقه‌بندي، پيمانه‌بندي سيستم راحت تر انجام پذيرد.
ماهيت طبقه‌بندي يك فرآيند تكرارشونده و فزاينده است. هرچقدر دانش و تجربه تحليلگر نسبت به دامنه مساله بيشتر مي‌شود ، دسته‌بندي بهتري از اشياء و كلاسها صورت مي‌گيرد و راه‌حل‌هاي بعدي بهتر ارائه مي‌شوند. ضمن اينكه هيچ طبقه‌بندي كامل نمي‌تواند باشد و بستگي به سمت و سوي نگاه تحليلگر به دامنه مساله دارد، كامل بودن آن بستگي به فراست و بصيرت خلاقانه تحليلگر دارد.
سه نوع ديدگاه عمومي براي طبقه‌بندي وجود دارد: در روش كلاسيك دسته‌بندي بر اساس يك يا چند ويژگي مشترك بين موجوديت‌هاي مورد مطالعه انجام مي‌گيرد. اما هميشه نمي‌توان يك دسته ويژگي را يافت نمود كه طبقه‌بندي اشياء را بر اساس آنها انجام داد. روش دوم طبقه‌بندي مفهومي اشياء است. در اين روش بخش‌بندي دسته‌ها بر اساس يك مفهوم انجام شده و سپس موجوديت‌ها با توجه به حداكثر تناسب با مفهوم ارائه شده براي هر دسته، در آن قرار مي‌گيرند. در اين روش يك موجوديت ممكن است در چند دسته قرار گيرد. در طراحي نرم‌افزارهاي پيچيده اغلب دو روش قبلي براي طبقه‌بندي اشياء قابل استفاده است. اما در برخي موارد صرفاً استفاده از دو روش مذكور كفايت نمي‌نمايد. در اين حالت روش نمونه اوليه بكار برده مي‌شود. در اين روش يك نمونه اوليه ازهر دسته مورد نظر ساخته مي‌شود و از اين پس هر شي كه بيشترين شباهت به نمونه اوليه را دارد در دسته مرتبط قرار مي‌گيرد. عملا اين سه روش اساس تئوري تحليل شي گراء مي‌باشند.
مرز بين تحليل و طراحي شيءگرا خيلي شفاف نيست. در تحليل شيءگرا تمركز بر روي بررسي كامل مسئله و مدل كردن دنياي آن مسئله بر اساس كلاسها و اشياء تشكيل‌دهنده آن است. در طراحي تجريدها و مكانيزمهايي براي فراهم ساختن شرايط حل مسئله ابداع مي‌شوند.
روشهاي اثبات شده‌اي در تحليل شيءگراء وجود دارد كه اساس آنها ديدگاه‌هاي عمومي مطرح شده در طبقه‌بندي اشياء است. اين روشها عبارتند از: تحليل كلاسيك، تحليل رفتاري، تحليل دامنه، تحليل سناريوهاي كاربردي، كارتهاي CRC، تحليل تشريح به زبان عامه و تحليل ساختيافته. در اغلب اين روشها، سناريوها نقش كليدي را ايفا مي‌نمايند.
در تحليل شيءگرا تجريدهاي كليدي كه شامل واژگان دامنه مسئله است نمايان مي‌شود. ضمن اينكه برخي تجريدهاي كليدي نيز در طي طراحي براي ساده‌تر كردن حل مسئله ايجاد مي‌شوند. مكانيزمها نيز تصميمات استراتژيك طراحي را كه نمايانگر تعامل بين اشياء مختلف دامنه مساله است مشخص مي‌نمايند.

گزيده:
اگر نمی‌‌تواني يهترين تكنسين‌ها(فني‌ها) را استخدام كني، بهترين مديران را استخدام كن! ماريا داتيز

مرجع: سايت مهندس رسول‌زادگان

Misconception #1: “SOA Vendor Stacks are Service Architectures”

Misconception #2: “SOA Vendor Stacks are the Best Foundation for SOA Engineering”

Misconception #3: “An ESB Product Equals Service Infrastructure”

Misconception #4: “SOA Performance is Available Off-the-Shelf”

Misconception #5: “SOA Security Architecture is Available Off-The-Shelf”

Misconception #6: “Programmers Will Define and Build Reusable Services”

Misconception #7: “SOA is a Process-Centric Architecture”

Misconception #8: “SSL/TLS is a Good Foundation for SOA Message Security”

Misconception #9: “All You Really Need are Web Services”

Reference: SOA Engineering Misconceptions

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