How should we approach computer science in education?
Ivar Jacobson: ... You can learn to do Java programming at a university level, or any other language they might have taught if you go back in time, but if you really want to understand software, you need to have competencies in many other different areas, such as requirements, architecture, testing, unit testing, integration testing, system testing, performance testing, not to mention configuration management, version control, differences between building frameworks and building applications, building reusable software, services-oriented architecture, product line architecture, and so on.
You can’t learn the really hard things in universities.
Reference: ?
Quote:
Fact 1: The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
Reference: Facts and Fallacies of Software Engineering By Robert L. Glass

An integrated development environment (IDE) also known as integrated design environment or integrated debugging environment is a software application that provides comprehensive facilities to computer programmers for software development.

برای مشاهده جداول مقایسه‌اي بين IDEهاي مختلف مي‌توانيد به آدرس زير مراجعه نماييد:

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

گزيده:

Common sense is the collection of prejudices acquired by age eighteen. Albert Einstein 

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

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

شناسايي پروژه‌هايي كه فرجامي جز شكست ندارند، خود از مهارتهاي مهم مهندسي است. در نوشته‌اي، نويسنده 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&D 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

كم‌هزينه‌ترين راه يادگيري،‌ استفاده از تجربه ديگران است. يادگيري‌اي كه هزينه‌اش را ديگران پرداخته‌اند. گريدي بوچ براي علاقه‌مندان حوزه مهندسي نرم‌افزار، فردي آشناست. با سابقه‌ای طولاني و تأثيرگذار. محقق ارشد شركت آي‌بي‌ام، تجربيات خود از توسعه سيستمهاي پيچيده نرم‌افزاري را در پنج بند خلاصه كرده است. براي همكاراني كه وضعيتهاي مشابهي را تجربه كرده‌اند، تك تك كلمات، راهبردي و راه‌گشاست. هر چند خيلي نمي‌توان راه‌كار اجرايي از نظرات گريدي بوچ استخراج كرد، ولي به عنوان يك استراتژي و چارچوب، مي‌توان آن را به كار گرفت. بخشهايي از نظرات ايشان را خلاصه كرده و در زير آورده‌ام. متن اصلي را مي‌توانيد در اينجا مطالعه نماييد.

- The fundamentals never go out of style

1. Create crisp and resilient abstractions.
   2. Maintain a good separation of concerns.
   3. Create a balanced distribution of responsibilities.
   4. Focus on simplicity.

The key in creating useful abstractions is to use an object-oriented view of the world, rather than an algorithm-based viewpoint.
Separation of concerns means, "You don't put the dishwasher in the bathroom." The specifics depend on the requirements, but he advises, "Semantically related things should be clustered together and kept separate where they are not.

Don't underestimate the importance of keeping things simple, he warns—or the difficulty of getting there. "It requires energy to develop simple things,"

- You need a regular rhythm of releases.
Every project needs a heartbeat.
Establishing that rhythm provides predictability and sustainability.

- Focus upon growing executable architectures.
IT managers need to govern around the architectural decisions rather than raw, running, naked code. "The code is the truth,". "But the code is not the whole truth."

- Create social structures that encourage innovation while still preserving predictability.
One long-standing point of contention is the degree to which, in those social structures, the manager is a participant in the actual software development process. The architect should also be an implementer, says Booch, even if a line is drawn between development and managers. But there's a danger of noisy communication when management gets too involved; it's the difference between a line and a wall.
Another component to creating innovative teams, says Booch, is keeping developers out of "blasted meetings" so they can get things done.

- Have fun.
That's not simply friendly advice; Booch believes that successful projects come from teams that are jazzed about what they're doing. "Most people want to build beautiful, elegant things," he says. "If you rob them of that, you're taking away the passion of the craftsman."

Quote:
there are only two ways to live your life. One is as though nothing is a miracle. The other is as though everything is a miracle. Albert Einstein

Requirements

1. Can you name a number of non-functional (or quality) requirements?
2. What is your advice when a customer wants high performance, high usability and high security?
3. Can you name a number of different techniques for specifying requirements? What works best in which case?
4. What is requirements tracing? What is backward tracing vs. forward tracing?
5. Which tools do you like to use for keeping track of requirements?
6. How do you treat changing requirements? Are they good or bad? Why?
7. How do you search and find requirements? What are possible sources?
8. How do you prioritize requirements? Do you know different techniques?
9. Can you name the responsibilities of the user, the customer and the developer in the requirements process?
10. What do you do with requirements that are incomplete or incomprehensible?

Functional Design

1. What are metaphors used for in functional design? Can you name some successful examples?
2. How can you reduce the user's perception of waiting when some functions take a lot of time?
3. Which controls would you use when a user must select multiple items from a big list, in a minimal amount of space?
4. Can you name different measures to guarantee correctness of data entry?
5. Can you name different techniques for prototyping an application?
6. Can you name examples of how an application can anticipate user behavior?
7. Can you name different ways of designing access to a large and complex list of features?
8. How would you design editing twenty fields for a list of 10 items? And editing 3 fields for a list of 1000 items?
9. What is the problem of using different colors when highlighting pieces of a text?
10. Can you name some limitations of a web environment vs. a Windows environment?

Technical Design

1. What do low coupling and high cohesion mean? What does the principle of encapsulation mean?
2. How do you manage conflicts in a web application when different people are editing the same data?
3. Do you know about design patterns? Which design patterns have you used, and in what situations?
4. Do you know what a stateless business layer is? Where do long-running transactions fit into that picture?
5. What kinds of diagrams have you used in designing parts of an architecture, or a technical design?
6. Can you name the different tiers and responsibilities in an N-tier architecture?
7. Can you name different measures to guarantee correctness and robustness of data in an architecture?
8. Can you name any differences between object-oriented design and component-based design?
9. How would you model user authorization, user profiles and permissions in a database?
10. How would you model the animal kingdom (with species and their behavior) as a class system?

Construction

1. How do you make sure that your code can handle different kinds of error situations?
2. Can you explain what Test-Driven Development is? Can you name some principles of Extreme Programming?
3. What do you care about most when reviewing somebody else's code?
4. When do you use an abstract class and when do you use an interface?
5. Apart from the IDE, which other favorite tools do you use that you think are essential to you?
6. How do you make sure that your code is both safe and fast?
7. When do you use polymorphism and when do you use delegates?
8. When would you use a class with static members and when would you use a Singleton class?
9. Can you name examples of anticipating changing requirements in your code?
10. Can you describe the process you use for writing a piece of code, from requirements to delivery?

Algorithms

1. How do you find out if a number is a power of 2? And how do you know if it is an odd number?
2. How do you find the middle item in a linked list?
3. How would you change the format of all the phone numbers in 10,000 static html web pages?
4. Can you name an example of a recursive solution that you created?
5. Which is faster: finding an item in a hashtable or in a sorted list?
6. What is the last thing you learned about algorithms from a book, magazine or web site?
7. How would you write a function to reverse a string? And can you do that without a temporary string?
8. What type of language do you prefer for writing complex algorithms?
9. In an array with integers between 1 and 1,000,000 one value is in the array twice. How do you determine which one?
10. Do you know about the Traveling Salesman Problem?

Data Structures

1. How would you implement the structure of the London underground in a computer's memory?
2. How would you store the value of a color in a database, as efficiently as possible?
3. What is the difference between a queue and a stack?
4. What is the difference between storing data on the heap vs. on the stack?
5. How would you store a vector in N dimensions in a datatable?
6. What type of language do you prefer for writing complex data structures?
7. What is the number 21 in binary format? And in hex?
8. What is the last thing you learned about data structures from a book, magazine or web site?
9. How would you store the results of a soccer/football competition (with teams and scores) in an XML document?
10. Can you name some different text file formats for storing unicode characters?

Testing

1. Do you know what a regression test is? How do you verify that new changes have not broken existing features?
2. How can you implement unit testing when there are dependencies between a business layer and a data layer?
3. Which tools are essential to you for testing the quality of your code?
4. What types of problems have you encountered most often in your products after deployment?
5. Do you know what code coverage is? What types of code coverage are there?
6. Do you know the difference between functional testing and exploratory testing? How would you test a web site?
7. What is the difference between a test suite, a test case and a test plan? How would you organize testing?
8. What kind of tests would you include for a smoke test of an ecommerce web site?
9. What can you do reduce the chance that a customer finds things that he doesn't like during acceptance testing?
10. Can you tell me something that you have learned about testing and quality assurance in the last year?

Maintenance

1. What kind of tools are important to you for monitoring a product during maintenance?
2. What is important when updating a product that is in production and is being used?
3. How do you find an error in a large file with code that you cannot step through?
4. How can you make sure that changes in code will not affect any other parts of the product?
5. How do you create technical documentation for your products?
6. What measures have you taken to make your software products more easily maintainable?
7. How can you debug a system in a production environment, while it is being used?
8. Do you know what load balancing is? Can you name different types of load balancing?
9. Can you name reasons why maintenance of software is the biggest/most expensive part of an application's life cycle?
10. What is the difference between re-engineering and reverse engineering?

Configuration Management

1. Do you know what a baseline is in configuration management? How do you freeze an important moment in a project?
2. Which items do you normally place under version control?
3. How can you make sure that team members know who changed what in a software project?
4. Do you know the differences between tags and branches? When do you use which?
5. How would you manage changes to technical documentation, like the architecture of a product?
6. Which tools do you need to manage the state of all digital information in a project? Which tools do you like best?
7. How do you deal with changes that a customer wants in a released product?
8. Are there differences in managing versions and releases?
9. What is the difference between managing changes in text files vs. managing changes in binary files?
10. How would you treat simultaneous development of multiple RfC's or increments and maintenance issues?

Project Management

1. How many of the three variables scope, time and cost can be fixed by the customer?
2. Who should make estimates for the effort of a project? Who is allowed to set the deadline?
3. Do you prefer minimization of the number of releases or minimization of the amount of work-in-progress?
4. Which kind of diagrams do you use to track progress in a project?
5. What is the difference between an iteration and an increment?
6. Can you explain the practice of risk management? How should risks be managed?
7. Do you prefer a work breakdown structure or a rolling wave planning?
8. What do you need to be able to determine if a project is on time and within budget?
9. Can you name some differences between DSDM, Prince2 and Scrum?
10. How do you agree on scope and time with the customer, when the customer wants too much?

Reference: NOOP.NL

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

گزارشی از پرخطرترین خطاهای برنامه‌نويسي را مطالعه كردم. فوق‌العاده بود. براي معماران نرم‌افزار، طراحان، برنامه‌نويسان، خريداران و صد البته هكرها! منبع و مرجع بسيار غني‌اي است. علاوه بر رتبه‌بندي و ارائه توضيحات كامل در مورد هر خطا، روشهاي پيشگيري و كاهش اثرات نامطلوب آن نيز در حوزه‌هاي مختلفي مانند طراحي و معماري، پياده‌سازي، نيازمندي‌ها، آزمون و عملياتي كردن نيز ذكر شده است.   

مي‌توانيد اصل گزارش را در اينجا پيدا كنيد.

(January 12, 2009) Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime.

The Top 25 Errors are listed below in three categories:
Category: Insecure Interaction Between Components (9 errors)
Category: Risky Resource Management (9 errors)
Category: Porous Defenses (7 errors)

CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
CWE-319: Cleartext Transmission of Sensitive Information
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-362: Race Condition
CWE-209: Error Message Information Leak
CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
CWE-642: External Control of Critical State Data
CWE-73: External Control of File Name or Path
CWE-426: Untrusted Search Path
CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
CWE-494: Download of Code Without Integrity Check
CWE-404: Improper Resource Shutdown or Release
CWE-665: Improper Initialization
CWE-682: Incorrect Calculation
CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-259: Hard-Coded Password
CWE-732: Insecure Permission Assignment for Critical Resource
CWE-330: Use of Insufficiently Random Values
CWE-250: Execution with Unnecessary Privileges
CWE-602: Client-Side Enforcement of Server-Side Security

Organization of the Top 25
CWE ID and name
Supporting data fields
Discussion
Prevention and Mitigations
Related CWEs
Related Attack Patterns 
Attack Frequency
Ease of Detection
Remediation Cost
Attacker Awareness

پس‌نوشت: خانم زهرا، اهم مطالب سايت مرجع را به فارسي ترجمه نموده‌اند. مي‌توانيد مطالب را در اينجا مطالعه نماييد. از خانم زهرا بابت تقبل اين زحمت، سپاسگزارم.

Quote:
We are satisfied by doing real work. Software is like a plant that grows: You can’t predict its exact shape, or how big it will grow;you can control its growth only to a limited degree. There are no rules for this kind of thing—it’s never been done before.
- Charlie Anderson, Architect, Borland Quattro Pro for Windows.

-REQUIREMENTS WORK UNITS
--Requirements Engineering Activity
--Requirements Engineering Tasks
--Requirements Engineering Techniques

-REQUIREMENTS-RELATED PRODUCERS
--Roles
--Teams
--Tools
--Organizations

-REQUIREMENTS LANGUAGES

Quote:
You can't depend on your eyes when your imagination is out of focus.
Mark Twain

در زیر اسامی ۲۵ مهندس نرم‌افزار معروف دنيا به انتخاب Jurgen Appelo آورده شده است. صرف نظر از اهميت موضوع و علمی یا غیرعلمی بودن روش، اسامي آمده در فهرست، نام‌هايي هستند كه بايد به خاطر سپرد و نوشته‌هايشان را از دست نداد.  

On Amazon.com I traced the best-selling books on software engineering, .....
I admit that my method is totally unresponsible, and ....

1  Steve McConnell  22,5%
2  Martin Fowler      20,7%
3  Kent Beck            15,4%
4  Grady Booch        13,3%
5  Joel Spolsky         12,5%
6  Tom DeMarco      10,9%
7  Erich Gamma       9,6%
8  Craig Larman       9,3%
9  Scott W. Ambler   8,1%
10  Alistair Cockburn 8,0%
11  Ivar Jacobson      7,5%
12  Edward Yourdon  6,8%
13  Ken Schwaber     6,0%
14  James Rumbaugh 5,6%
15  Mike Cohn           5,5%
16  Andrew Hunt       5,2%
17  Robert L. Glass    4,5%
18  Frederick P. Brooks 4,3%
19  Jim Highsmith      3,9%
20  Paul Graham        3,9%
21  Philippe Kruchten  3,7%
22  Timothy Lister       3,7%
23  Mary Poppendieck 3,5%
24  Karl E. Wiegers     3,1%
25  Barry Boehm         2,7%

Quote:
I don't mind how much my Ministers talk, so long as they do what I say. Margaret Thatcher

• Principals are those people who will make the determination to pay for our software to achieve specific business goals, or who are perhaps key influencers in this purchase decision.
• End users are of course the people who will use our software to do a part, or even all, of their job.
• Partners are people who will use our software to help others meet their business goals; e.g., business partners who install, maintain, or deploy our software for a customer. Another example might be a particular customer's IT shop: they perhaps didn't buy our software or don't use it, but they have to get it running so that end users can.
• Insiders are the people we work with in our own organizations who have views about what should be in our software. This could be sales, marketing, executives, corporate, other developers; anyone we work with who has an opinion about what our product should do or how it should be built.
  

 Quote:
The biggest difficulty in software development is the communication between the people writing the software and the people for who the software is being written.  Martin Fowler

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

As part of the ‘Patterns and Styles’ paper presentations track, Neil B. Harrison and Paris Avgeriou presented a paper titled Analysis of Architecture Pattern Usage in Legacy System Architecture Documentation. The authors looked at different architectural and studied their usage in different application domains such as....

Here are some of their findings:

* The five most commonly used patterns are (in sequence): Layers, Shared Repository, Pipes and Filters, Broker and MVC.

* In Enterprise Systems, the most common used patterns are Layers, MVC, Presentation Abstraction Control and Broker.

* In Web-based systems, broker, layers, pipes and Filters are most prevalent. (This surprised me considering MVC is not in the list).

* One of the interesting results is that architectures are often based on 2 patterns rather than one, three or more patters.

* The authors also looked at the usage patterns of architectural view and found that out of the 4+1 views, development and process views are prevalent.

مرجع:‌Rabah's Weblog 

گزيده:
وقتي هدفمان را از دست مي‌دهيم، مجبور هستيم سعي خود را چند برابر كنيم .  مارك تواين

پس از نوشتن مطلب درد مشترک به نقل از وبلاگ رادمان، آقای ابوذر نوذری پیشنهاداتی در این زمینه ارائه داده‏اند كه ضمن تشكر از ايشان، پيشنهاداتشان در ادامه آورده شده است:

«همه اینها مشکلاتی هستند که تقریبا به طور عام در سایر صنایع کشور هم دیده می شوند، که البته با شدت و ضعف همراه می باشند. شاید به نوعی بتوان گفت در ایران، در کل تولید مزیت بالایی ندارد. که همه این موارد ناشی از ضعف اساسی ما در ایران، یعنی مدیریت است. نقطه ضعفی که متاسفانه از بالاترین سطوح تا پایین ترین سطوح در کشور و در همه عرصه ها به وضوح دیده می شود.
و اما به نظر من نرم افزار پچیدگی ها و حالات خاص خود را دارد. و در این میان مسئولیت این ضعف ها را شاید نتوان متوجه یک گروه خاص نمود. می توان با اندکی تقریب سهم دانشگاه ها و مراکز تحقیقاتی، مدیران و صاحبان صنعت نرم افزار، پرسنل و افراد فعال در این صنعت را در این رکود، رخوت و بی نظمی به یک اندازه دانست. البته به نظر من سهم دولت و دستگاه های سیاست گذاری صنعتی کشور در این میان کمی بیشتر است. متاسفانه علیرغم تاکید دولت های مختلف بر مساله فناوری اطلاعات ولی در هیچ یک از آنها به صنعت نرم افزار توجه جدی نشده است.
اما به نظر من راهکارهایی که در این حوزه برای نجات شرکت های نرم افزاری می توان مطرح کرد عبارتند از :

• آغاز یک حرکت نرم و تدریجی در راستای تغییر دیدگاه در تولید نرم افزار از رویکرد استادکاری به رویکرد مهندسی
• آغاز یک حرکت نرم و تدریجی به سوی تولید علمی نرم افزار بر اساس روش های صنعتی ارائه شده و تلاش برای خروج از سبک فعلی تولید که همانا سبک و شیوه کارگاهی و غیر صنعتی می باشد
• تلاش برای شکل گیری انجمن های قوی صنفی نظیر کنسرسیوم ها و ... جهت حمایت از حقوق صنعت نرم افزار و شرکت های نرم افزاری
• تلاش برای ارتباط هر چه بیشتر با شرکت های فعال نرم افزاری در خارج از ایران جهت مشارکت در پروژه های داخلی و انتقال تکنولوژی و مهمتر از آن سبک، شیوه، تفکر و روح حاکم کاری در آن شرکت ها به داخل کشور
• تلاش برای گسترده تر کردن ارتباط با ایرانیانی که در خارج از کشور در شرکت های بزرگ نرم افزاری مشغول به کار هستند، و دعوت از آنها، از طرف صنایع نه دانشگاه ها، برای حضور در ایران و ارائه کنفرانس ها و کارگاه های آموزشی کاربردی
• تلاش برای تغییر دیدگاه بنگاه های مالی و اعتباری کشور نظیر بانک ها و موسسات پولی به صنعت نرم افزار
• سرمایه گذاری هر چه بیشتر در نیروی انسانی و آموزش آنها همراه با اتخاذ روش هایی جهت پایبند کردن آنها به شرکت
• به کارگیری سود حاصل از پروژه های نرم افزاری در همین صنعت
• تلاش برای ترویج مفاهیم اقتصاد مهندسی در همه سطوح اعم از مدیران ارشد شرکتهای نرم افزاری تا کارشناسان و پرسنل درگیر در سطوح پایین هرم
• تلاش برای ارتباط با صاحب نظران جهت انجام آسیب شناسی های دقیق و تکنیکی در این حوزه و ارائه راهکار برای آن

و در پایان همه این موارد نیاز به گذشت مدت زمانی طولانی جهت شکل گیری و قوام دارند. مواردی که مطرح شدند چیزهایی نیستند که در طول یک سال و دو سال بدست آیند، و دقیقا من هم به همین خاطر در اکثر جملات کلمه "تلاش" را به کار برده ام. چیزی که من حس می کنم این است که مجموع حرکت ها در صنعت نرم افزار ایران، حداقل در مقطع فعلی، گویای حرکت در یک مسیر درست و روبه کمال نمی باشد. در نهایت می توانم بگویم که صنعت نرم افزار در ایران از مسائلی مثل ابزار محوری، فرد محوری، عدم وجود دیدگاه مهندسی و سیستماتیک، عدم وجود دیدگاه بلند مدت و ترجیح منافع کوتاه مدت و میان مدت بر منافع بلند مدت و مسائلی از این دست به شدت رنج می برد.
امیدوارم دوستان دیگر با مشارکت خود در تکمیل این بحث و به خصوص ارائه راهکار کمک نمایند.»

گزیده:
" اگر در اولين قدم، موفقيت نصيب ما می‏شد، سعی و عمل ديگر معنی نداشت"  . موريس مترلينگ

مأخذ: سخن بزرگان

«این روزها فرصتی فراهم شده است که با چند شرکت متوسط و بزرگ نرم افزاری از نزدیک آشنا شوم، نه آنطوری که خود را برای مشتریان خود نمایش می دهند، آنگونه که واقعا هستند. مواجه شدم با یک "حقیقت ساده" انکه سایز شرکتها هر چقدر هم که باشد گویی با یک سری مشکل مشابه مواجه هستند:
1- مشکلات ناشی از سرمایه ناکافی که قدرت ریسک را از شرکتها می گیرد.
2- بزرگ شدن بدون آنکه الزامات بزرگی را رعایت کرده باشند و خود را برای آن آماده کرده باشند.
3- مشتریانی که همیشه ناراضی هستند
4- مشکلات مدیریت نیروی انسانی که گویی کسی که بتوان بیش از یک سال رویش حساب کرد دیگر به سختی یافت می شود.
5-نداشتن دید مالی و بازرگانی نزد مدیران شرکتها و قوی تر بودن وجه فنی این افراد
6- مظلومیت تولید کنندگان نرم افزار که حاصل دسترنجشان به کمترین هزینه فروش می رود در حالیکه مشتری بابت سخت افزار همان نرم افزار چندین برابر هزینه می کند.
7- عدم وجود و یا کارآمدی قوانینی که حقوق این شرکتها را در مقابل تکثیر غیر قانونی نرم افزارشان، ترک کار نیروهایشان و سرقت اطلاعات طراحی سیستمهای آنها حفظ کند.
8- رقابت ناسالمی که برخی همکاران غیر حرفه ای ایجاد می کنند.
9- وابستگی شدید اقتصاد کشور به دولت که با کوچکترین نوسانش بزرگ و کوچک شرکتها هم آسیب می بینند و عدم توانایی رقابت واقعی با شرکتهای خارجی در خارج از مرزها
10- و در آخر همان حکایت کوزه گر و کوزه شکسته، نبود سیستمها و نرم افزارهای مناسب در شرکتها برای مکانیزه کردن فرآیندها در این شرکتها چه در سطح داخلی و چه در سطح مديريت روابط مشتريان»
شاید بتوانم 90 تای دیگر هم به این نکات اضافه کنم. مواردی که همه فعالان این صنعت همه می دانند و هر یک به نوعی درگیر آن هستیم، اما چاره چیست؟ نظر شما در این زمینه کدام است؟
در مورد اصلاح ساختاری شرکتهای نرم افزاری برای توانمند سازی آنان در مقابل مشکلات و دشواری ها مطلب خواهم نوشت. اما پیش از آن مایلم تجربیات شما را در این زمینه بدانم.
همین!

گزیده:
به عوض آنکه به تاريکی لعنت بفرستيد، شمع روشن کنيد. «کنفوسيوس»

یادآوری: نويسنده محترم به دنبال روشن كردن سهم خود از شمعهاست كه جاي سپاس و قدرداني دارد.

"Architecture is the work of a single architect."
"A great architecture is the work of a single architect. " Fred Brooks wrote this in 1975.
Granted, there are some great examples of this: But in practice, geniuses are rare, and in many organizations good architectures are most often the work of a small group of people working as a team.
The architecture team acts as a team as defined by Katzenbach and Smith A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.
So the architecture team is not a committee, meeting every Tuesday at 15:00; it is not a problem clearinghouse; it is not an ivory tower, a resting place for successful but tired designers.
Especially for complex systems, a well-chosen architecture team is needed to bring the right mix of domain and software engineering experience, and the right mix of design specialties (hence minimizing the [my favorite architecture] effect mentioned above). The architecture team needs significant flexibility in composition and structure. Some of the architects may become the architects of subsystems, once those have been defined.
However, it is important to have a clearly designated team leader: a lead software architect who can drive the effort, arbitrate, resolve conflicts, and bring timely closure to project tasks.
Philippe Kruchten

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

Reuse is something that is far easier to say than to do. Doing it requires both good design and very good documentation. Even when we see good design, which is still infrequently, we won't see the components reused without good documentation.
- D. L. Parnas, _Software Aging. Proceedings of 16th International Conference Software Engineering, 1994

گزیده:

Learn from the mistakes of others. You won't live long enough to make all of them yourself. (Sam Levenson) 
John M. Nevison, 13 Risk Rules for New Project Managers

"Architecture is [insert favorite technology here]."
"The network is the architecture. The database is the architecture. The transaction server is the architecture. The GUI is the architecture. CORBA is the architecture. This standard is the architecture..." This is a special case of the previous point. Yes, many of these aspects are part of the architecture, but the architecture cannot be restricted to one aspect only.
Architecture is more than just a "technology watch," but I see many organizations in which the major role of the software architect seems to be experimenting with interesting new technologies. Often this is also the consequence of having architects who all come from one single specialty: for example, an architecture team comprised solely of data engineers. I was told recently: "We do not need anybody to work on architecture; our company has standardized on three-tier client-server architecture."

Philippe Kruchten

گزیده:

The three most useless things to a project manager are: unnecessary product features, yesterday's calendar, and "90% done" work.
John M. Nevison, 13 Risk Rules for New Project Managers

"Architecture is design."
Yes, architecture is design. It is about making the difficult choices on how the system will be implemented. It is not just the "what." But not all design is architecture.
Architecture is one aspect of the design, focusing on the major elements -- the elements that are structurally important, but also those that have a more lasting impact on the performance, reliability, cost, and adaptability of the system. Architecting is choosing the small set of mechanisms, patterns, and styles that are going to permeate the rest of the design and give it its integrity. Architecture is the tool that allows us to master complexity. It cannot be the whole design. It has to limit itself to a certain level of abstraction but still be concrete enough to draw definite conclusions. It is not just "high-level design."

What shall the architect focus on, then? There is no universal answer. For  any given project, a decision needs to be made about what is  architecturally significant so that we can draw that thin and elusive line between architecture and the rest of the design activities.

"Architecture is infrastructure."
Yes, the infrastructure is an integral and important part of the architecture: It is the foundation. Choices of platform, operating systems, middleware, database, and so on, are major architectural choices.
But there is far more to architecture than just the infrastructure. The architects have to consider the whole system, including all applications; otherwise an overly narrow view of what architecture is may lead to a very nice infrastructure, but the wrong infrastructure for the problem at hand.
Time and time again, I run into this in organizations in which an architecture team is working solely on infrastructure, largely ignorant of the problem domain and the application software -- which they consider to be outside of the architecture. "Oh, you mean the application. That's what the people in the other building do."

Philippe Kruchten

گزیده:

Projects aren't dangerous. Risks are dangerous.
John M. Nevison, 13 Risk Rules for New Project Managers

مبدع آن، خانم Wirfs-Brock است. کتاب ایشان با نام  Designing Object-Oriented Software منتشر شده به سال 1990، یکی از تأثیرگذارترین کتابهای حوزه طراحی شیءگرا بوده است.

در سایت شرکتشان در مورد ایشان آمده است:

Rebecca Wirfs-Brock, who founded Wirfs-Brock Associates in 1997, is an object technology innovator and pioneer. Having invented Responsibility-Driven Design while at Tektronix in 1990, she has pushed on “object thinking” for the past 15 years.

توصیه می‏کنم کتاب جدیدتر ایشان با نام Object Design: Roles, Responsibilities, and Collaborations را مطالعه کنید. همچنین بد نیست مصاحبه ایشان را در OOPSLA2007 را که بهانه نوشته این مطلب بود، در اینجا ببینید و بشنوید.

گزیده:

Never let a project go somewhere your plan didn't go a month earlier.
John M. Nevison, 13 Risk Rules for New Project Managers

Over the last decade or two, a philosophy has developed as an undercurrent in the object community. The premise of domain-driven design is two-fold:

• For most software projects, the primary focus should be on the domain and domain logic; and
• Complex domain designs should be based on a model.

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

مرجع: http://www.domaindrivendesign.org/
گزیده:

Every project needs an ending, but not every project needs to be started.
John M. Nevison, 13 Risk Rules for New Project Managers

Concept-orientation is a new emerging programming, data modelling and system design paradigm. The main purpose of this site is to serve as a growing resource sharing and organizing the work and thoughts on this new direction in computer science for those interested in learning about it.
Main principles of the concept-oriented programming:
1. Separation of business methods (BMs) and representation and access (RA) methods.
2. Objects live in spaces and any BM call has to intersect a sequence of borders in order to access the object.
3. The spaces where objects live have a hierarchical structure.
4. Transparency of access.
Reference: The Concept-Oriented Portal

گزیده:
اگر مي خواهي براي حال و آينده مفيد باشي از گذشته درس بگير)ناپلئون(
مرجع:کمتر از 10 دقیقه

For the individuals considering a change in job, the reasons can be as many and varied as the personalities involved. For the organization with pathologically high turnover,a few reasons account for most departures:

• a just-passing-through mentality: Co-workers engender no feelings of long-term involvement in the job.
• a feeling of disposability: Management can only think of its workers as interchangeable parts (since turnover is so high, nobody is indispensable).
• a sense that loyalty would be ludicrous: Who could be loyal to an organization that views its people as parts?

آیا شما دلایل دیگری را هم سراغ دارید؟
مرجع: کتاب Productive Projects and Teams 2nd ed نوشته Tom DeMarco & Timothy Lister

گزیده:

The things two people do to each other they remember. If they stay together, it's not because they forget; it's because they forgive.  - Demi Moore in Indecent Proposal

حال که موضوع حقوق کاربران به میان آمد، می‏خواهم لطيفه‏ای تعریف کنم با یادی از دوست خوبم، احسان (که دیرزمانی است که او را ندیده‏ام و واقعاً دلم برایش تنگ شده است)، چرا که این لطیفه را اولین بار برایم تعریف کرد.
می‏گویند یکی از هلی‏کوپترهای یکی از پایگاه‏های نظامی آمریکا در یکی از مأموریتهایش، مسیر بازگشت به پایگاه را گم کرد. خلبان ساختمانی را در آن نزدیکی دید، نزدیک ساختمان شد و کمک خلبان چیزی روی کاغذ نوشت و به کارکنانی که در ساختمان پشت کامپیوترهایشان مشغول کار بودند، نشان داد. کارکنان هم در جواب، نوشته‏ای روی کاغذ نوشتند و به خلبان و کمک خلبان نشان دادند.
خلبان نگاهی به نقشه‏ای که کنارش بود، انداخت و به سمت پایگاه پرواز کرد. بعد از چند ساعت، فرمانده پایگاه با آقای بیل گیتس تماس گرفت و از ایشان و کارمندان مایکروسافت بابت راهنمایی خلبان، تشکر کرد. آقای گیتس که متعجب شده بود، جویای جریان شد. فرمانده پادگان، خلبان را خواست تا برای آقای گیتس، ماجرا را شرح دهد. خلبان گفت که وقتی ما گم شده بودیم، کمک خلبان روی کاغذ نوشت که "ما کجا هستیم؟" و به کارمندان نشان داد. آنها هم در پاسخ نوشتند که "شما در هلی‏کوپتر هستید".  من و کمک خلبان به این نتیجه رسیدیم که اینجا، جایی نیست جز ساختمان شرکت مایکروسافت. از روی نقشه، آنجا را پیدا کردیم و به کمک آن به پایگاه برگشتیم.

نکته: طنز اشاره دارد به پیغامهای نرم‏افزارهای شرکت مایکروسافت که خنده‏دارترین پیغامها را برای راهنمایی کاربر اعلام می‏کنند.

گزیده:
درویش ضعیف حال را در خشکی تنگسال مپرس که چونی؟ الا به شرط آن که مرهم ریشش بنهی و معلومی پیشش.
خری که بینی و باری به گل درافتاده                به دل برو شفقت کن ولی مرو به  سرش
کنون که رفتی و پرسیدیش که چون افتاد         میان ببند و چون مردان بگیر دمب خرش

ریش = زخم
گلستان سعدی، باب هشتم، حکایت بیست و نهم

چند وقت پيش در وبلاگهای برخی از دوستان از جمله مهندسی نرم‏افزار، به موضوعی اشاره شده بود با عنوان "حق با مشتری است یا نه؟".
این موضوع از وجوه مختلف قابل بررسی است. در اینجا می‏خواهم به نتیجه تحقیق دکتر Karat(دکترای روانشاسی) در مرکز تحقیقات واتسون شرکت IBM در سال 1998 با عنوان حقوق کاربران کامپيوتر (Computer User's Bill of Rights) اشاره کنم.
موارد زیر حقوقی است که ما برای کاربران قائل شدیم، پس راهی برای احترام به حقوق دیگران باید پیدا کنیم  اگر می‏خواهیم حقوق خودمان رعایت شود. 

1. The user is always right. If there is a problem with the use of the system, the system is the problem, not the user.
2. The user has the right to easily install software and hardware systems.
3. The user has the right to a system that performs exactly as promised.
4. The user has the right to easy-to-use instructions for understanding and utilizing a system to achieve desired goals.
5. The user has the right to be in control of the system and to be able to get the system to respond to a request for attention.
6. The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion.
7. The user has the right to be clearly informed about all system requirements for successfully using software or hardware.
8. The user has the right to know the limits of the system's capabilities.
9. The user has the right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns.
10. The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use.

گزیده:
خلعت سلطان اگر چه عزیز است، جامه خلقان خود به عزت‏تر. خوان بزرگان اگر چه لذیذ است، خرده انبان خود به لذت‏تر.
سرکه از دسترنج خویش و تره                      بهتر از نان دهخدا و بره
گلستان سعدی، باب هشتم، حکایت هشتاد و دوم

با خواندن مطلب زیر نه تنها مطالب جدیدی یادگرفتم، بلکه به شدت خندیدم. خلاصه‏ای از آن را در اینجا آورده و آدرس آن را نیز در ادامه آورده‏ام.

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code.

* Documentation : 
   Any fool can tell the truth, but it requires a man of some sense to know how to lie well.

* Program Design :
The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.

*Testing:
I don't need to test my programs. I have an error-correcting modem.

*Dealing With Others:
Hell is other people.

*Roll Your Own:
You've always wanted to write system level code. Now is your chance. Ignore the standard libraries and write your own. It will look great on your resumé.

*Miscellaneous Techniques:
If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime.

refs: http://www.web-hits.org/txt/codingunmaintainable.html

گزیده:
لقمان را گفتند: ادب از که آموختی؟ گفت از بی‏ادبان. هر چه از ایشان در نظرم ناپسند آمد، از فعل آن پرهیز کردم.
نگویند از سر بازیچه حرفی  --- کزان پندی نگیرد صاحب هوش
وگر صد باب حکمت پیش نادان --- بخوانند آیدش بازیچه در گوش
گلستان سعدی، باب دوم، حکایت بیستم.

I'm passionate about creating great software, I believe creating great software can help create great businesses: either its the software products you sell or the software that allows the business to be great.
I believe software systems done well can help us grow and learn as businesses and as individuals; done badly they can hold us back. Software alone is not enough: you have to learn and change, this is how we create knowledge.
The immediate problem I see is: how do we make our software development better? How do we improve the team? Yet this is only the start of the problem, the real problem is: how do I make my business better? How do I improve my products and services?
ref: http://www.allankelly.net/

گزیده:

Alfredo: [after informed about the arrival of the new non-combustible film] Progress always comes late. --Cinema Paradiso

حتماْ داستان مشاور را خوانده‏اید. این داستان را خیلی سال پیش یکی از دوستانم برایم تعریف کرد. بسیاری از دوستانم که دارای پستهای مهمی در شرکتهای مختلف بودند، در گروههای پستی، چندین و چند بار برایم فرستادند. این داستان را بار دیگر در اینجا دیدم و آن را در زیر آورده‏ام. یادم هست یک بار مدیر عامل یکی از بزرگترین شرکتهای نرم‏افزاری به من گفت: یکی از مهمترین دلایل مؤفقیت من، داشتن مشاورهای بسیار توانا بوده است.  خیلی دوست دارم که نظرات دوستانم را در این مورد بدانم. منتظر هستم.

"چوپاني مشغول چراندن گله گوسفندان خود در يك مرغزار دورافتاده بود. ناگهان سروكله يك اتومبيل جديد كروكي از ميان گرد و غبار جادههاي خاكي پيدا ميشود. رانندگي آن اتومبيل كه يك مرد جوان با لباس Brioni ، كفشهاي Gucci ، عينك Ray-Ban و كراوات YSL بود، سرش را از پنجره اتومبيل بيرون آورد و پرسيد: اگر من به تو بگويم كه دقيقا چند راس گوسفند داري، يكي از آنها را به من خواهي داد؟
چوپان نگاهي به جوان تازه به دورانرسيده و نگاهي به رمهاش كه به آرامي در حال چريدن بود، انداخت و با وقار خاصي جواب مثبت داد.
جوان، ماشين خود را در گوشهاي پارك كرد و كامپيوتر Notebook خود را به سرعت از ماشين بيرون آورد، آن را به يك تلفن راه دور وصل كرد، وارد صفحهي NASA روي اينترنت، جايي كه ميتوانست سيستم جستجوي ماهوارهاي ( GPS ) را فعال كند، شد. منطقهي چراگاه را مشخص كرد، يك بانك اطلاعاتي با 60 صفحهي كاربرگ Excel را به وجود آورد و فرمول پيچيدهي عملياتي را وارد كامپيوتر كرد.
بالاخره 150 صفحهي اطلاعات خروجي سيستم را توسط يك چاپگر مينياتوري همراهش چاپ كرد و آنگاه در حالي كه آنها را به چوپان ميداد، گفت: شما در اينجا دقيقا 1586 گوسفند داري.
چوپان گفت: درست است. حالا همينطور كه قبلا توافق كرديم، ميتواني يكي از گوسفندها را ببري.
آنگاه به نظارهي مرد جوان كه مشغول انتخاب كردن و قرار دادن آن گوسفند در داخل اتومبيلش بود، پرداخت. وقتي كار انتخاب آن مرد تمام شد، چوپان رو به او كرد و گفت: اگر من دقيقا به تو بگويم كه چه كاره هستي، گوسفند مرا پس خواهي داد
مرد جوان پاسخ داد: آري، چرا كه نه!
چوپان گفت: تو يك "مشاور" هستي.
مرد جوان گفت: راست ميگويي، اما به من بگو كه اين را از كجا حدس زدي؟
چوپان پاسخ داد: كار سادهاي است. بدون اينكه كسي از تو خواسته باشد، به اينجا آمدي. براي پاسخ دادن به سوالي كه خود من جواب آن را از قبل ميدانستم، مزد خواستي. مضافا، اينكه هيچ چيز راجع به كسب و كار من نميداني، چون به جاي گوسفند، سگ مرا برداشتي."

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

گزیده:

waiting for you is like waiting for rain in this drought, hopeless and disappointing.
-Hillary Duff (A Cinderella Story)

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
• Performance Effort or time
• Complexity Volume of human-generated code
• Process Maturity of process and notation
• Team  Skill set, experience, and motivation
• Tools  Software 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

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

ماهنامه The Rational Edge در شماره اخير خود مقاله‏ای با عنوان What makes software so hard دارد که به نکات جالبی اشاره کرده است.
هر چند اين موضوع در مراجع مختلف و از ديدگاههای مختلف بررسی شده است، اما مرور آن خالی از لطف نيست.
در اين مقاله به مقايسه مهندسی نرم‏افزار با ساير حوزه‏های رايج مهندسی پرداخته است.
بخش جمع‏بندی و نتيجه‏گيری مقاله را در زير آورده‏ام.

Software is hard for a number of fundamental reasons:
    * Software projects are design projects, not production projects.
    * Because software is pure mindware, software development is more of an art or craft than a science or engineering discipline, making the "doing" disciplines of software development difficult to perform, monitor, and measure. Productivity differences between individuals are huge.
    * Software lacks laws and first principles.
    * Software lacks a measurable standard unit of work.
    * Given software's flexibility, the "supporting" disciplines of software projects -- planning, estimation, prediction and observation -- are quite difficult.
    * Moore's law makes the foundations of software ever changing -- there's no "permanent" platform to build on.
Even though it might be tempting to consider software engineering as "just another engineering discipline," and thus jump to the conclusion that software can be developed using the same business, management, and engineering principles as traditional engineering, there are some unique characteristics that make software and software development not only special, but also more difficult to estimate and monitor than traditional engineering projects.
Software development, with its inherent characteristics, existing in a very dynamic world governed only by Moore's law, will remain more art than a science for a long time to come. We can only hope to tackle the problems in software development by acknowledging that software is different, and understanding the consequences of these differences.
Any attempts to regard software development as just another form of traditional engineering will generally not deliver the desired results. Only by having a good understanding of what makes software different, can we start addressing the unique issues associated with software development. Iterative development, modeling, requirements management, and early-and-often stakeholder involvement are among the techniques available to software teams who recognize this critical difference and are looking for a new way forward.

گزيده:
لغت نامه مهندسين در جلسات كارفرما
پروژه بدليل بعضى مشكلات ديده نشده، كمى از برنامه ريزى عقب است. يعنى: تاكنون روى پروژه ديگرى كار مى كرديم!
ما تصحيحاتى روى سيستم انجام داديم تا آن را ارتقا دهيم. يعنى: تمام طراحى ما اشتباه بوده و ما از اول شروع كرده ايم!