After using RUP templates for software architecture specification for few years, we at Eurocenter have decided to build our own set of templates for Software Architecture and for Software Design specifications. The new templates needed to provide enough meta-information to the author for better analyze the system as well as not to miss any important design aspect.

we use 4 types of design documentations:
1-‘Architecture Overview Document’ which presents the very abstract view of our recommended architecture to solve the customer problem as well as several alternative architectures with merits/demerits.

2-‘Software Architecture Specification’, describing the meta-structure of all software structures. Our approach in this document is based on 4+1 views described by Philippe Kruchten.
3-we perform a detail design analysis based on UML notations to bridge the gap between system architecture and implementation. We call this document the ‘Software Design Specification’.

4-‘Developer Guideline Documentation’ which serves the purpose of documenting miscellaneous guidelines for the developers. This section may include some best practices, version controlling guide lines, project specific knowledge base, etc.

Let’s have a look at the key attributes in developing a software architecture specification. You may use the following as a checklist to verify that you do not miss any important architectural aspect. Basically these are related with the non-functional goals of your architecture. Perfect system architecture may describe the expected level and realization strategy for each of the following attributes:

Reference: Hasith Yaggahavita’s Blog

گزیده:
در عالم دو چیز از همه زیباتر است: آسمانی پرستاره و وجدانی آسوده. کانت

f you’re a process engineer, process analyst, or a team leader looking to standardize on a commercially available framework for your organization’s software development efforts, this article is for you. My objective is to point out the similarities and differences between the Rational Unified Process®, or RUP®, and the Microsoft Solutions Framework (MSF).

گزیده:
آنانکه نمی‌توانند گذشته را به‌ياد بياورند، محکوم به تکرار آنند. جورج سانتا پانا

This is a photo from the 2009 Obama Presidential Inauguration, in which you can see IN FOCUS the face of each individual in the crowd!!

http://gigapan.org/viewGigapanFullscreen.php?auth=033ef14483ee899496648c2b4b06233c

The picture was taken with a robotic camera at 1,474 megapixel.(295 times the standard 5 megapixel camera). Special software allows scanning and zooming in on any part of the picture to see details.
You can double click and zoom to any section of the crowd…wait a few seconds… and the focus adjusts.
Reference: An email from Dr. Farhad

گزيده:
ما از اينکه نکند تمام زندگيمان به‌هدر رود وحشت داريم، اما هر روز از تکه‌تکه دور ريختن آن ابائی نداريم. جان هاو

Standish Group بیشتر با گزارشهاي CHAOS شناخته می‌شود .
آمارهايي كه دراين گزارش از مؤفقيت يا شكست پروژه‌هاي نرم‌افزاري و عوامل تأثيرگذار بر آنها، ارائه مي‌گردد، مرجع بسيار مناسبي است براي آن كه در اجراي و انجام پروژه‌هاي نرم‌افزاري به فكر تبيين راه‌كارهايي براي بروز يا عدم بروز آنها باشيم..

ديگر كاربرد اين آمار، ارقام و تحليل‌ها، ارائه ادله قابل استناد مبتني بر داده‌هاي آماري براي تأكيد بر اهميت بسياري حوزه‌هاي مهندسي نرم‌افزار است . به عنوان مثال، هر گاه مي‌خواهم اهميت حوزه‌ي مهمي مانند «مهندسي نيازمندي‌‌ها» را يادآور شوم،‌ عوامل شكست و مؤفقيت پروژه‌ها را بر اساس آمارهاي سالهاي متمادي CHAOS فهرست مي‌كنم.
با اين مقدمه، آمارها و تحليلهاي سال 2006 اين گزارش را به صورت تصاويري در زير آورده‌ام.
مرجع:InfoQ

گزيده:

A little learning is a dangerous thing.
Alexander Pope

In no particular order, you know you’re not doing agile if:
1. The team is co-located, but people are not sitting within the length of a school bus to each other.

2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.

3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.

4. If no user has seen real running software inside the last month.

5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.

6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.

7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.

8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.

9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.

10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Reference: Alistair Cockburn

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

آقاي علي اعرابي، دوست عزيز و مهربانم، آدرسي را برايم فرستاده بود كه حاوي مطلبي بود با عنوان «سخنان بزرگان درباره برنامه نویسی!». بخشی از آن را در زیر آورده‌ام.

زمانی‌ که کد می‌نویسید فرض کنید شخصی که قرار است در آینده از کدهای شما نگهداری کند یک دیوانه‌ی زنجیری است که آدرس خانه‌ی شما را می‌داند! (Rick Osborne)

تنها دو صنعت هستند که به مصرف کنندگان خود “کاربر” می‌گویند: صنعت کامپیوتر و تجارت مواد مخدر! (ناشناس)

تنها دو نوع زبان برنامه نویسی وجود دارد: آنهایی که برنامه نویس‌ها از آن شکایت دارند و آن‌هایی که اصلا مورد استفاده قرار نمی‌گیرند! (Bjarne Stroustrup- خالق ‍‍++C)

هر کسی می‌تواند کدی بنویسد که یک کامپیوتر آن‌را درک کند. یک برنامه نویس خوب کدی را می‌نویسد که برای سایر همکارانش قابل درک باشد. (Martin Fowler)

اندازه‌گیری درصد پیشرفت یک پروژه برنامه نویسی با شمارش تعداد سطرهای کدهای آن همانند اندازه گیری درصد پیشرفت ساخت یک هواپیما از طریق وزن کردن آن است! (Bill Gates)

صحبت کردن ساده است. کدت رو نشون بده! (Linus Torvalds)

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

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

1- The project name changes for the third time in as many months.

2- The requirements definition is begun four months after development started.

3- The newly hired director of R proudly informs the board of directors that the project will be 99 percent completed six months ahead of schedule

4-You realize the reason the company hired you as a consultant is to referee a dispute among two competing departments over which technical platform to use.

5-The developer doesn’t understand the spec document and continues to develop anyway. And the QA team doesn’t know how to test, but they “test” anyway.

6-When you see the project budget, you realize that over half of it was spent on a Web designer to create a Photoshop mock-up of the home page—with no regard to whether that design is feasible.

7-The user or client requests new features instead of focusing on bug fixing and performance enhancements

8-You find a list of 16 software development best practices and realize that not a single one of them is being followed

9-The technical project manager asks you to compose the list of user requirements—without consulting any actual potential users.

10-The new CIO replaces all the people who have deep organizational knowledge with outsiders from his old firm.

11-The program manager decided to try Agile methodology “to save time.”

12-The lead developer tells you that maintaining a complete history of all database updates is a requirement for the application, but he hasn’t had time to (read: doesn’t know how to) design a data model for it yet. So he decides to go ahead and start with the Web front end and worry about it later. And this is the lead developer.

Quote:
It is hard to fail, but it is worse never to have tried to succeed. Theodore Roosevelt