Hỏi: Khách hàng của chúng tôi rất đòi hỏi, họ thường không biết điều họ muốn nhưng đối xử với người phát triển của chúng tôi rất tệ. Làm sao chúng tôi có thể cải tiến sự thoả mãn của khách hàng khi chúng tôi thậm chí không biết các trông đợi của họ?

Đáp:  Tôi tin thuật ngữ “Khách hàng” nghĩa là các cá nhân hay nhóm người dùng sản phẩm hay dịch vụ của bạn.  Khi cố gắng quản lí các mong đợi của khách hàng, điều quan trọng là xem xét cách đối xử với khách hàng và không hội tụ vào bản thân dịch vụ hay sản phẩm. Bạn cần hỏi cái gì là quan trọng cho bạn khi bạn là khách hàng – Khi bạn đi tới tiệm ăn, đi chợ, mua bán v.v. Bạn sẽ trông đợi ít nhất cũng là mức độ kính trọng nào đó, sự nhã nhặn lịch sự, chú ý, chất lượng sản phẩm, thuận tiện, và tin cậy. Những trông đợi này có thể được tách ra thành hai loại:

1)  – Những trông đợi có liên quan tới sản phẩm và dịch vụ (chẳng hạn, chất lượng và tính dự kiến được) là các yếu tố kĩ thuật.

2)  – Những trông đợi có liên quan tới cách chúng ta được đối xử (chẳng hạn, kính trọng và chân thành) là các yếu tố con người.

Bây giờ chúng ta hãy tự hỏi mình câu hỏi này: cái gì làm cho bạn đổi sản phẩm hay mua từ nhà cung cấp khác? Nó là yếu tố kĩ thuật hay yếu tố con người? Tôi nghĩ 30% mọi người sẽ đổi bởi vì không thoả mãn với sản phẩm nhưng 70% mọi người sẽ đổi bởi vì họ không thoải mái với cách họ  bị đối xử. Thông điệp rõ ràng là ở chỗ chúng ta nên hội tụ nhiều hơn vào yếu tố con người khi chúng ta làm việc để cải tiến cách chúng ta giải quyết với khách hàng. Điều này không có nghĩa là bạn có thể có sản phẩm tồi trong khi bạn đối xử kính trọng với con người. Tuy nhiên, điều đó không chỉ dẫn rằng đặt hội tụ vào cách đối xử con người có thể cho phép bạn thoát được một vấn đề nhỏ trong sản phẩm hay dịch vụ.

Để quản lí trông đợi của khách hàng, tôi gợi ý rằng tổ chức của bạn nên thiết lập “qui trình” để thúc đẩy hiểu biết chung giữa khách hàng và người phát triển đối với dịch vụ, trách nhiệm và ưu tiên. Theo định nghĩa, “qui trình chính thức” này là thoả thuận giữa hai nhóm được thiết kế để quản lí trông đợi về dịch vụ và chất lượng mức dịch vụ, trách nhiệm cho cả hai nhóm cũng như các bước cả hai nhóm có thể làm để thành công. Ích lợi then chốt của “Qui trình chính thức” được làm tài liệu là tăng nhận biết cho cả hai nhóm về những nhạy cảm của nhau. Nó cũng đề cập tới sự kiện là phía này (thường là khách hàng) thường thậm chí không biết rằng họ cũng có trách nhiệm làm công việc này. “Qui trình chính thức” này phải bao gồm:

1)     Công cụ trao đổi. (Cách họ trao đổi lẫn nhau)

2)     Công cụ ngăn ngừa xung đột.  (Cách giải quyết xung đột và leo thang tới đúng người có thể quyết định)

3)     Thủ tục được làm tài liệu — như tương phản với hợp đồng. (Hợp đồng thường được tạo ra đơn phương ở chỗ bắt đầu và bị gạt ra  mãi cho cho tới khi một bên cảm thấy cần dùng nó để nêu vấn đề hay để thu được sự thúc bẩy.)

4)     Qui trình khách quan để điều phối tính hiệu quả của loại dịch vụ này.

Tất nhiên, nó không nên được dùng như chức năng áp đặt hay bị coi như cơ chế “phàn nàn.” Ngược lại, qui trình này mời thêm nhiều trao đổi. – “Qui trình chính thức” sẽ không có tác dụng nếu nó được tạo ra đơn phương bởi một bên và bị áp đặt lên bên kia. Phần của điều làm cho nó có tác dụng là ở chỗ việc tạo ra nó và những cập nhật về sau đều có cả hai bên làm việc cùng nhau. – Do đó nó không phải là cố định nhanh chóng, nó là một phần của hoạt động cải tiến qui trình. Điều quan trọng cần nhớ là việc quản lí thành công các mong đợi không có nghĩa là bạn bao giờ cũng đáp ứng trông đợi nhưng nó quả có tạo ra khả năng là có hiểu biết chung về các trông đợi.

Hỏi: Làm sao tôi làm cho người quản lí của mình, người chỉ tập trung vào việc làm tiền, chuyển sang hội tụ vào cải tiến qui trình?

Đáp: Để có được sự hỗ trợ của người quản lí này, bạn có thể dùng dữ liệu công nghiệp đã công bố để chỉ ra cách cải tiến qui trình có thể giúp cho cải tiến doanh nghiệp (tức là tiết kiệm tiền). Ý tưởng then chốt là đặt quan hệ tất cả các hoạt độnhg cải tiến với việc tiết liệm tiền như giảm chi phí, việc làm lại, khiếm khuyết và thời gian ra thị trường nhanh hơn. Về tổng thể, bằng việc trưởng thành trong tổ chức tốt hơn, bạn có thể tiết kiệm tới 70% chi phí phát triển và đó là lợi nhuận thuần. Tất nhiên, để có được tiết kiệm đó, bạn phải đầu tư vào cải tiến qui trình.

 

Hỏi: Khuôn khổ CMMI có thể được dùng cho các tổ chức nhỏ quãng 20 tới 60 người không?

Đáp: Có chứ. CMMI đã được dùng thành công bởi nhiều tổ chức nhỏ, nhỏ cỡ 20 người. Kích cỡ không phải là nhân tố khi bạn muốn cải tiến qui trình. Tất nhiên, bạn phải áp dụng phán xét của mình vào điều thích hợp trong miền nào đó, với hướng dẫn được CMMI cung cấp.  Xin lưu ý rằng CMMI không phải là yêu cầu về bạn phải làm cái này hay làm cái nọ. Không có gì bắt buộc trong CMMI cho nên bạn có thể sửa đổi nó cho khớp với môi trường nhỏ của mình. Về cơ bản tổ chức nhỏ sẽ dễ thay đổi hơn nhiều so với tổ chức lớn.

 

Hỏi: Tôi tin Cải tiến qui trình sẽ không bao giờ có tác dụng trừ phi người phát triển phần mềm đồng ý thực hiện nó. Tôi có đúng không?

Đáp: Bạn cần nhiều hơn chỉ là người phát triển phần mềm. Toàn thể tổ chức phải đồng ý cải tiến qui trình và cam kết làm cho mọi sự xảy ra. Với “cam kết” tôi ngụ ý rằng cả người quản lí và người phát triển đều phải hiểu cải tiến tất cả là gì, chấp nhận các vai trò và trách nhiệm được phân công cho họ, và hỗ trợ tất cả các hoạt động cải tiến. Để tôi nêu cho bạn vài ví dụ:

Tôi biết một tổ chức mà cấp quản lí đã ra quyết định cải tiến qui trình phần mềm của họ. Họ thành lập SEPG và khởi đầu một chương trình cải tiến qui mô lớn. Những người phát triển phần mềm phàn nàn một cách cay đắng khi họ phải trải qua hàng giờ dài họp hành, trình bày, hội thảo, và không có thời gian làm công việc dự án thực. Thỉnh thoảng, người chủ công ti bước vào và yêu cầu “việc thực” cần được làm. Đó là chấm dứt cam kết của cấp quản lí làm cải tiến qui trình.

Trong tình huống khác, người phát triển mệt mỏi vì bị lái đi theo lịch biểu phi lí và tỉ lệ thay đổi yêu cầu. Họ khởi đầu một chương trình cải tiến, xác định các qui trình riêng của mình, thiết lập các thủ tục riêng của mình, và cấp quản lí cảm thấy họ bị thách thức bởi nhóm những người phát triển có tính nổi dậy này. Họ tin mọi sự đang “tuột khỏi kiểm soát” và bắt đầu hành động. Điều đó cũng là việc chấm dứt của người hành nghề muốn làm cải tiến qui trình.

Để làm việc cải tiến qui trình xảy ra, mọi người trong tổ chức từ đỉnh tới đáy phải cam kết đưa điều đó vào hoạt động.

Hỏi: Nhiều năm trước, phần mềm chậm trễ, chi phí quá nhiều, và được chuyển giao với ít chức năng. Ngày nay phần mềm vẫn chậm trễ, chi phí khá cao, và tạo ra ít chức năng hơn người dùng cần.  Nó có tiến bộ không?

Đáp: Trong bốn mươi năm qua, cái gì đó đã thay đổi và cái gì đó khác lại không đổi. Công nghiệp phần mềm đã đổi từ nỗi đau “mã mì sợi” thành niềm vui của “lập trình có cấu trúc” hay “thiết kế hướng đối tượng.” Họ đã từ bỏ gõ mã nguồn trên “bìa đục lỗ” để dùng các công cụ phát triển thuận tiện khác. Bạn có lẽ không biết “bìa đục lỗ” trên máy tính lớn hay “mã sợi mì” COBOL nếu bạn không làm việc quãng 40 năm trước, những việc đó rất tẻ nhạt, tốn thời gian và sinh lỗi. Những máy tính đó bây giờ chỉ có trong bảo tàng.

Tất nhiên, nhiều dự án phần mềm vẫn bị tụt lại sau lịch biểu, vượt quá ngân sách, và không thể chuyển giao điều khách hàng cần. Nhiều người đã kết luận rằng lí do chính là kích cỡ lớn, phức tạp hơn, và môi trường làm việc tồi kiểu như lịch biểu không hợp lí và các yêu cầu không ổn định.

Tuy nhiên, tôi nghĩ điều đó phần lớn là do thiếu kỉ luật kĩ nghệ phần mềm bởi vì có các tổ chức sản xuất ra phần mềm chất lượng cao, đáp ứng mọi nhu cầu khách hàng trong ràng buộc ngân sách và thời gian. Nhiều tổ chức trong số họ đã được thẩm định ở mức trưởng thành rất cao. Đó là lí do tại sao tôi nghĩ cải tiến qui trình là rất quan trọng và Mô hình trưởng thành năng lực tích hợp Capability Maturity Model Integration (CMMI) là mô hình tốt để cải tiến năng lực của tổ chức phần mềm thông qua kĩ nghệ phần mềm có kỉ luật.

 

Hỏi: Chúng tôi là tổ chức CMMI mức 1. Liệu có thể thực hiện tất cả các Miền qui trình một lúc để cho chúng tôi có thể cải tiến nhanh hơn được không?

Đáp: Bạn cần tự hỏi mình: “Mình muốn điều đó nhanh hay muốn điều đó đúng?” Đi từ CMMI mức 1 lên CMMI mức 2 là một bước rất lớn. Bạn cần lập kế hoạch việc thực hiện trong nhiều bước tăng nhỏ dựa trên môi trường doanh nghiệp của mình. Phần lớn các tổ chức chỉ lựa một hay hai miền một lúc để thực hiện. Dựa trên kinh nghiệm của tôi, miền tốn thời gian thực hiện nhất là Quản lí yêu cầu và Lập kế hoạch dự án phần mềm.

 

Hỏi: Tôi đã đọc sách CMMI ba lần và đã thảo luận nó với bạn bè mình. Chúng tôi nghĩ nó chẳng là gì ngoài “cái vô nghĩa quan liêu.” Thầy nghĩ gì?

Đáp: Tôi không đồng ý với kết luận của bạn. Đừng chỉ “đọc sách” mà bạn cần hiểu ý định đằng sau từ ngữ. CMMI chỉ là khuôn khổ, không phải là yêu cầu bạn phải làm cái gì đó tương ứng. Nó phát biểu tường minh rằng bạn phải áp dụng đánh giá chuyên nghiệp (không có quan liêu ở đây) và cho phép những việc thực hiện thay phiên nếu điều đó có nghĩa cho công ti bạn. Về căn bản, CMMI hội tụ vào “cái gì” chứ không vào “thế nào.” Nó cho phép mọi người quyết định miền nào họ cần hội tụ vào để cải tiến doanh nghiệp phần mềm của họ. Bạn cần hiểu ý định thực của các tác giả và dùng CMMI chỉ như bản hướng dẫn để cải tiến qui trình của bạn.

 

Hỏi: Tổ đánh giá tìm kiếm cái gì làm bằng chứng của Quản lí yêu cầu?

Đáp: Với việc đánh giá tôi sẽ tìm các yêu cầu được làm tài liệu (đặc tả, yêu cầu thay đổi v.v.) và tính theo dõi được từ các yêu cầu tới việc thực hiện thực tế (mã). Tôi cũng muốn biết liệu mọi người thực hiện các yêu cầu có nhận được huấn luyện nào hay có kinh nghiệm nào (với CMMI mức 2, kinh nghiệm có thể được thay thế cho huấn luyện nhưng với CMMI mức 3 việc huấn luyện bắt buộc phải có cho tất cả mọi người thực hiện việc đó). Bạn cũng phải chắc chắn rằng tất cả các nhóm bị ảnh hưởng (Kiểm thử, SCM, SQA v.v.) cũng tham gia vào hoạt động quản lí yêu cầu.

Hỏi: Làm sao thầy áp dụng CMMI cho các dự án tích hợp phần mềm thương mại Commercial-Off-The-Shelf (COTS)? Chúng tôi dùng SAP cho hệ thống ERP của mình.

Đáp: Chắc chắn có một số quan tâm khi thực hiện cải tiến trong môi trường tích hợp COTS nhưng các nguyên tắc nền tảng của lập kế hoạch, quản lí, trao đổi, v.v., như được mô tả trong mục đích của miền then chốt chắc chắn sẽ áp dụng – cứ tự hỏi mình việc thực hiện hợp lí của thực hành này cho dự án đặc biệt này, mình có cần tuân theo miền này hay không.

 

Hỏi: Có bao nhiêu kiểu chuẩn kĩ nghệ phần mềm hay chuẩn tính toán? Chúng là gì? Những ủng hộ và phản đối gì đối với việc tuân theo chuẩn?

Đáp: Có nhiều chuẩn Kĩ nghệ phần mềm hay Chuẩn tính toán trong công nghiệp ngày nay. Sau đây là phân loại của tôi:

1)  Kiểu Chuẩn tính toán:

Kĩ nghệ phần mềm

Truyền thông và Mạng

Giao diện người dùng

Đa phương tiện

Quản lí dữ liệu

Đồ hoạ

Trao đổi dữ liệu

Hệ điều hành

Nhân tố con người

Quản trị hệ thống

An ninh

Tính toán phân bố

2)  Chuẩn kĩ nghệ phần mềm:

Qui trình vòng đời phần mềm

Thu nhận phần mềm

Môi trường kĩ nghệ phần mềm

Cách đo phần mềm

Ngôn ngữ lập trình

Quản lí cấu hình

Kiểm thử hệ thống

Mô hình hoá & Mô phỏng

Quản lí chương trình

Chuẩn giao diện

Quản lí rủi ro

Đảm bảo chất lượng

Nếu bạn hỏi 100 người về lí do tuân theo hay không tuân theo chuẩn bạn có thể có 150 câu trả lời vì một số người có thể có nhiều ý kiến. Sau đây là một số ý kiến:

PHẢN ĐỐI:

1)     Hội tụ vào chuẩn bao giờ cũng gây ra nhấn mạnh vào làm tài liệu, thay vì công việc thực.

2)      Coi tuân thủ chuẩn là hoạt động không có giá trị gia tăng bởi vì mọi người đằng nào cũng hay bỏ qua chuẩn.

3)      Chi phí cho việc thực hiện chuẩn là cao và khó ước lượng.

4)      Phần lớn các chuẩn kĩ nghệ phần mềm của tổ chức thường thiếu hướng dẫn để điều chỉnh theo dự án.

5)      Môi trường của chúng ta KHÔNG cho phép tuân theo chuẩn

6)      Đảm bảo chất lượng, Trắc nghiệm và Kiểm nghiệm, và SEPG dùng các chuẩn như cái cớ để làm các hoạt động không gia tăng giá trị.

7)      Không có phương tiện xác định tính hiệu quả của việc tuân theo chuẩn phần mềm.

8)      Tuân theo chuẩn dẫn tới niềm tin giả: Tuân thủ theo các điều khoản liên quan của chuẩn thích hợp giúp đảm bảo sản phẩm chất lượng, đúng thời gian, trong ngân sách.

ỦNG HỘ:

1)     Tập tích hợp các chuẩn phần mềm là khuôn khổ cho việc xác định qui trình phần mềm.

2)     Chuẩn có thể giúp trong việc nắm bắt tri thức chuyên gia tập thể của tổ chức liên quan tới các hoạt động bản chất và sản phẩm công việc.

3)     Chuẩn có thể là cơ sở cho thoả thuận hay hợp đồng giữa khách hàng và người phát triển.

4)     Chuẩn có ích trong việc tạo điều kiện thuận lợi cho sự nhất quán qua các dự án, tổ chức và ngành công nghiệp.

5)     Chuẩn thúc đẩy thuật ngữ chung, các định nghĩa và hành động như cơ sở cho truyền thông.

6)     Chuẩn thúc đẩy kĩ nghệ phần mềm tốt và thực hành phát triển.

7)     Chuẩn qui trình thích hợp tạo ra cơ sở cho qui trình phần mềm lặp lại được, điều có thể được điều chỉnh theo nhu cầu dự án.

 

———-English version——————-

 

CMMI-2

Question: Our customer is very demanding, they often do not know what they want but treat our developers very badly. How can we improve customer satisfaction when we do not even know their expectations?

Answer:  I believe the term “Customer” means individuals or groups that use your product or service.  When trying to manage customer’s expectations, it is important to consider how the customer is treated and not focus on the service or product itself. You need to ask what is important to you when you are the customer – When you go to a restaurant, shopping, buying etc. You would expect at least some degree of respect, courtesy, attention, quality products, convenience, and trust. These expectations can be separated into two categories:

1)  – Those that are related to the product or service (for example,   quality and predictability) are the technical element.

2)  – Those that are related on how we are treated (for example, respect and honesty) are the human element.

Now let’s ask yourself the question: what would cause you to change your product or buying from other providers? Is it technical element or human element? I think 30% people would change because of dissatisfaction with the product but 70% of people would change because of they are unhappy with how they were treated. The clear message is that we should focus more on the human element as we work on improving how we deal with our customers. This doesn’t mean that you can have a bad product as long as you treat people with respect. However, it does indicate that putting focus on how people are treated can allow you to get away with a small issue in product or service.

To manage customer’s expectation, I suggest that your organization establishes a “process” to promote a common understanding between your customer and developers regarding; services, responsibilities, and priorities. By definition, this “formal process” is an agreement between two groups designed to manage expectations in the services and service level quality, the responsibilities of both groups as well as the steps both groups can take to succeed. A key benefit of a documented “formal Process” is to increase awareness by both groups of each other’s sensitivities. It also addresses the fact that frequently one side (often the customer) doesn’t even know that they also have responsibilities to make this work. This “Formal Process” must include:

1)     A communication tool. (How they communicate with each other)

2)     A conflict prevention tool.  (How conflict can be resolved and escalate to the right person who can make decision)

3)     A documented procedure — as contrasted with a contract. (Contracts are frequently created unilaterally at the outset and put away until one party feels the need to use one to make a point or gain leverage.)

4)     An objective process for monitor the effectiveness of this kind of service.

Of course, it shouldn’t be used as a forcing function or looked at as a “complaint” mechanism. On the contrary, this process invites more communications. – A “Formal Process” won’t work if it is unilaterally created by one side and imposed on the other. Part of what makes it work is that its creation and subsequent updates involve the two parties working together. – It is not a quick fix therefore it is part of a process improvement activity. It is important to remember that successful management of expectations doesn’t mean that you always meet expectations but it does increase the likelihood that there is a common understanding of expectations.

 

Question: How do I get my manager who only focuses on making money to focus on process improvement?

Answer: To get this manager’s support, you could use published industry data to show how process improvement can help improve the business (i.e. save money). The key idea is to relate all improvement activities to money savings such as reduce cost, rework, defects and faster time to market. Overall, by mature into a better organization, you could save up to 70% of development cost and that is pure profit. Of course, in order to get that saving, you must invest in process improvement.

 

Question: Can the CMMI framework be used for a small organization about 20 to 60 people?

Answer: Yes, The CMMI has been successfully used by many small organizations, as small as 20 people. Size should not be a factor when you want to improve the process. Of course, you have to apply your judgment as to what is appropriate in certain area, given the guidance supplied by the CMMI.  Please note that the CMMI is not a requirement that you must do this or do that. There is nothing that is mandatory in the CMMI so you could modify it to fit your small environment. Basically it is much easier for small organization to change than a larger one.

 

Question: I believe Process Improvement will never work unless software developers agree to do it. Am I correct?

Answer: You need more than just software developers. The entire organization has to agree to improve the process and committed to make thing happen. By “committed” I mean that both managers and developers must understand what improvement is all about, accept the roles and responsibilities assigned to them, and support all improvement activities. Let me give you some examples:

I knew an organization where management made the decision to improve their software process. They established an SEPG and initiated a massive improvement program. The software developers complained bitterly when they had to endure long hours of meetings, presentations, workshops, and did not have time to do real project work. After a while, the company owner stepped in and demand “real work” to be done. That was the end of management commitment to do process improvement.

In another situation, developers were tired of being driven by unreasonable schedule and the rate of requirements change. They initiated an improvement program, defined their own processes, established their own procedures, and management felt they were being challenged by a group of rebellious developers. They believe things were getting “out of control” and began to take action. That was also the end of practitioner want to do process improvement.

To make process improvement happen, everybody in the organization from top to bottom must agree and commit to make it works.

 

Question: Many years ago, software was late, cost too much, and delivered with little functionality. Today software is still late, cost significantly high, and produce substantially less functionality than user needed. Is it progress?

Answer: In the past forty years, something has changed and some has not. The software industry has traded the pain of “spaghetti code” for the joys of “structure programming” or “Object oriented design”. They have given up typing source code on “punched cards” for the convenience of other development tools. You probably do not know “punched card” on the mainframe computer or COBOL “Spaghetti code” unless you have worked about 40 years ago but it is very tedious, time consuming and error prone. Those computers are now in the museum.

Of course, many software projects are still behind schedule, over budget, and unlikely to deliver what the customer needs. Several people have concluded that the main reasons are larger size, more complex, and bad work environment such as unreasonable schedule and unstable requirements.

However, I think it is mostly due to the lack of software engineering disciplines because there are organizations that produce high quality software, meet all customers’ needs within budget and time constraints. Many of them were assessed at very high level of maturity. That is why I think process improvement is very important and the Capability Maturity Model Integration (CMMI) is a good model to improve the capability of the software organization via a disciplined software engineering.

 

Question: We were CMMI Level 1 organization. Is it possible to implement all Process Areas at once so we can improve faster?

Answer: You need to ask yourself: “Do I want it fast or want it right?” Moving from CMMI Level 1 to CMMI Level 2 is a very big step. You need to plan your implementation in several small incremental steps based on your business environment. Most organizations select only one or two area at a time to implement. Based on my experience, the most time-consuming areas to implement are Requirements Management and Software Project Planning.

 

Question: I have read CMMI book three times and discussed it with my friends. We think it is a nothing but “bureaucracy nonsense”. What do you think?

Answer: I do not agree with your conclusion. Do not just “read the book” but you need to understand the intension that goes beyond words. The CMMI is only a framework, not a requirement that you must do something accordingly. It explicitly state that you have to apply professional judgment (No bureaucracy here) and allows alternate implementations if it make sense to your company. Basically, the CMMI focuses on “What” rather than “How”. It allows people to decide what area that they need to focus on to improve their software business. You need to understand the true intent of the authors and use the CMMI only as guidance for improving your process.

 

Question: What does an appraisal team be looking for as evidence of Requirements Management?

Answer: For an appraisal I will look for documented requirements (Specifications, Change requests, etc.) and the traceability from requirements to actual implementation (Code). I also want to know if people perform requirements receive any training or have experience (For CMMI level 2, experience can be substituted for training but for CMMI level 3 required mandatory training for all people performing that job). You also have to make sure that all affected groups (Test, SCM, SQA etc.) also participate in requirements management activities

 

Question: How do you apply the CMMI to a Commercial-Off-The-Shelf (COTS) integration projects? We use SAP for our ERP system.

Answer: Certainly there are some concerns when implementing improvement in a COTS integration environment but the fundamental principles of planning, managing, communicating, etc., as described in the goals of the key area would certainly apply – just ask yourself what is a reasonable implementation of this practice for this particular project, do I need to follow this area or not.

 

Question: How many types of software engineering or computing standards are there? What are they? What are the pros and cons of following a standard?

Answer: There are many Software Engineering or Computing Standards in the industry today. Following are my classification:

1)  Types of Computing Standards:

Software Engineering

Communications and Network

User Interface

Multimedia

Data Management

Graphics

Data Interchange

Operating System

Human Factors

Systems Management

Security

Distributed Computing

2)  Software Engineering Standards:

Software Life Cycle Processes

Software Acquisition

Software Engineering Environments

Software Metrics

Programming Languages

Configuration Management

System Test

Modeling & Simulation

Program Management

Interface Standards

Risk Management

Quality Assurance

If you ask 100 people about the reason to follow or not follow a standard you may have 150 answers since some may have more than one opinion. Following are some:

CON:

1)     Focus on standards always cause emphasis on documentation, rather than real work.

2)     Treating standards conformance is non-valued added activity because most people often ignored standards anyway.

3)     Cost of implementing standards is high and difficult to estimate

4)      Most organization’s software engineering standards often lack    guideline for tailoring to project.

5)     Our environment do NOT allow following standards

6)     Quality Assurance, Verification &Validation, and SEPG use standards as an excuse to do non-values added activities.

7)     There’s no means of determining effectiveness of following a software standard

8)     Following standards lead to false confidence: Compliance with relevant provisions of appropriate standards helps ensure quality product, on-time, within budget

PRO:

1)     An integrated set of Software standards is a framework for software process definition.

2)     Standards can help in capturing collective expertise of organization regarding essential activities and work products.

3)     Standards can be a basis for agreement or contract between customer and developer.

4)     Standard is helpful in facilitate consistency across projects, organization, and industry.

5)     Standard promotes common terminology, definitions and act as a basis for communication.

6)     Standard promotes good software engineering and development practices.

7)     Appropriate process standards form a basis for a repeatable software process, which can be tailored to project needs.