CMMI-15

GS John Vu20/05/2024 12:00
CMMI-15

Hỏi: Tổ chức của chúng tôi muốn tiến hành việc đánh giá để xác định chúng tôi ở đâu trong mức trưởng thành CMMI. Các bước và vấn đề là gì?

Đáp: Sau đây là các bước trong việc đánh giá điển hình:

1.      Xác định phạm vi, mục đích cải tiến và thiết lập sự bảo trợ.

2.      Thiết lập kết cấn nền thực hiện (SEPG)

3.      Lập kế hoạch chi tiết đánh giá.

4.      Chuẩn bị và huấn luyện tổ đánh giá.

5.      Lập hồ sơ các thành viên đánh giá (thành viên dự án phần mềm).

6.      Người quản trị bảng hỏi CMMI.

7.      Phân tích đáp ứng bảng hỏi.

8.      Kiểm điểm vật phẩm và tài liệu.

9.      Tiến hành phỏng vấn với các đại diện miền chức năng (SQA, CM).

10.    Tiến hành phỏng vấn người quản lí, người hành nghề, người lãnh đạo dự án.

11.    Hợp nhất dữ liệu thu được từ các bảng hỏi, kiểm điểm và phỏng vấn.

12.    Thiết lập phát kiến và khuyến cáo.

13.    Xác định mức trưởng thành.

14.    Lập hồ sơ bảo trợ về kết quả đánh giá.

15.    Lập hồ sơ các thành viên đánh giá về kết quả.

16.    Lập hồ sơ tổ chức về kết quả đánh giá.

17.    Chuẩn bị báo cáo đánh giá cuối cùng.

Việc đánh giá nên được tiến hành bởi những người đánh giá được SEI công nhận và dựa trên nguyên tắc mật. Độ chính xác và tính hữu dụng của kết quả phụ thuộc cực kì lớn vào khả năng của mọi người nói một cách tự do và không sợ trừng phạt, trù úm. Nhà tư vấn không đủ tư cách có thể làm mọi người lẫn lộn, đặt mong  đợi sai, và đưa tổ chức xuống con đường sai với những hứa hẹn nhưng không giữ lời và cuối cùng làm hỏng việc cải tiến.

Hỏi:  Tại sao SEPG cũng chịu trách nhiệm cho việc chuyển giao công nghệ trong tổ chức? Tại sao không phân công cho người kĩ thuật khác làm nhiệm vụ này?

Đáp: Khi công nghệ phần mềm mới được đưa vào trong tổ chức, những thay đổi có ý nghĩa cần được xảy ra trong tổ chức đó để đảm bảo việc chấp nhận thành công. Điều này là đúng dù công nghệ là qui trình (như Kiểm điểm), kỉ luật (như Quản lí dự án) hay công cụ (như RUP).

Trong quá khứ, tổ chịu trách nhiệm đưa vào công nghệ mới cho tổ chức thường là những người kĩ thuật nhưng nhiều việc chuyển giao công nghệ đã thất bại. Dựa trên dữ liệu được thu thập tôi thấy rằng phần lớn các thất bại đều không phải công nghệ hay qui trình  mà do thiếu chỉ dẫn và huấn luyện kĩ năng trong những người chịu trách nhiệm làm cho thay đổi xảy ra. Phần lớn mọi người đều có kĩ năng kĩ thuật nhưng không có kĩ năng cần thiết để lập kế hoạch và thực hiện việc chuyển giao công nghệ thành công.

Các thành viên SEPG là các nhà chuyên môn kĩ thuật, được huấn luyện để đưa thay đổi vào trong tổ chức và rất quen thuộc với “qui trình thay đổi.” Do đó, họ là những người có thể nhất được phân công làm “tác nhân thay đổi” chịu trách nhiệm cho việc chuyển giao công nghệ trong tổ chức.

Hỏi: Định nghĩa về tổ kĩ nghệ phần mềm “tốt” là gì? Người làm phần mềm có phải làm việc trong “tổ” không?

Đáp: Câu hỏi của bạn làm tôi nghĩ tới một cuộc họp tôi có với một nhóm người làm phần mềm từ một công ti. Họ nói rằng “tổ phần mềm tốt” là tổ được tạo nên từ người tốt – định nghĩa về “người tốt” là họ và chỉ họ.

Tổ kĩ nghệ phần mềm “tốt” có thể khó định nghĩa bởi vì một số vấn đề như sự khác biệt về nền tảng và phong cách cũng như cảm giác cá nhân về “có tính sáng tạo cao” hay “tốt hơn” ai đó khác. Tuy nhiên, với việc đưa vào bộ môn kĩ nghệ phần mềm, thời của “tôi là trung tâm” đã qua rồi. Tôi đã biết nhiều tổ phần mềm tốt nơi mọi người đều trưởng thành, chuyên nghiệp, và sẵn lòng chia sẻ tri thức của mình với nhau. Tổ tốt yêu cầu trộn lẫn các kĩ năng, người nọ bổ sung cho người kia để đạt tới mục đích chung. Điều đó áp dụng cho bất kì tổ nào và phần mềm là không khác.

Hỏi: Thầy coi dự án thành công là gì? Nhân tố mấu chốt là gì?

Đáp: Dự án được coi là thành công chỉ nếu các mục tiêu chi phí, lịch biểu, và chất lượng được đáp ứng. Nhân tố mấu chốt trong dự án là qui trình ước lượng, điều giúp cho người quản lí dự án trong việc quản lí và kiểm soát chi phí dự án và theo lịch biểu để đạt tới chức năng được yêu cầu. Người quản lí dự án chỉ nên cam kết với dự án khi họ có ước lượng chi phí và lịch biểu mà theo đó họ có mức độ tin cậy nào đó.

Không một phương pháp ước lượng chuẩn nào là phù hợp cho mọi kiểu dự án. Từng tổ chức đều cần định nghĩa một qui trình ước lượng phù hợp với nhu cầu riêng của mình.

Một số mục cần xem xét khi xác định qui trình ước lượng của bạn bao gồm:

  • Khi nào việc ước lượng và tái ước lượng được thực hiện?

  • Ai thực hiện ước lượng?

  • Cái gì đặc biệt được ước lượng, như nỗ lực, tải, phần mềm, kích cỡ v.v.?

  • Làm sao điều phối và kiểm soát ước lượng?

  • Nếu có sai biệt giữa thực tại và ước lượng, khi nào bạn làm tái ước lượng?

  • Điều gì xảy ra khi ước lượng không được cấp quản lí chấp nhận? không được khách hàng chấp nhận?

  • Nếu yêu cầu thay đổi khi nào bạn làm tái ước lượng?

  • Khi nào bạn sẽ không làm tái ước lượng?

  • Cách đo nào của các dự án trước (cách đo dự án, cách đo qui trình) được ghi lại trong cơ sở dữ liệu tổ chức?

  • Cách đo của các dự án trước được duy trì thế nào để cải tiến ước lượng chi phí phần mềm?

Hỏi: Tại sao mọi người lại phí thời gian học các kĩ năng cải tiến qui trình khi họ có thể học các kĩ năng khác như JAVA, C++, và OOD để làm nhiều tiền hơn và có cơ hội làm việc tốt hơn?

Đáp: Các kĩ năng cải tiến qui trình phần mềm ít được chú ý hơn cái gọi là kĩ năng “kĩ thuật” như C++, JAVA, tích hợp mạng, và OOD. Vậy mà nhiều tổ chức lại tìm kiếm cải tiến vị thế cạnh tranh của họ qua các qui trình phần mềm tốt hơn, nhu cầu về các nhà chuyên môn cải tiến qui trình có kĩ năng cũng đang tăng trưởng. Có mối quan tâm tăng lên về cải tiến qui trình phần mềm trên khắp thế giới. Nhu cầu về các nhà chuyên môn này đang tăng trưởng nhanh hơn nhu cầu về cái gọi là “kĩ năng kĩ thuật” với đề nghị việc có lương cao hơn nhiều các lĩnh vực khác. Bất kì ai cũng có thể học JAVA và C++ ở trường học nhưng chưa có trường nào dạy kĩ năng về cải tiến qui trình. Bạn phải thực hành nó và học nó.

Hỏi: Một nhà tư vấn khuyên chúng tôi làm tài liệu mọi thứ để cho chúng tôi có thể đạt được CMMI mức 3. Dường như là mọi người đều xô vào việc viết tài liệu qui trình bây giờ. Cải tiến qui trình có phải tất cả là vậy không?

Đáp: Cải tiến qui trình phần mềm được xác định là “các hoạt động cải tiến qui trình phần mềm tổ chức để đạt tới kết quả đặc biệt.” Kết quả cuối cùng có thể là việc giảm chi phí, khiếm khuyết, và thời gian chu kì nhưng không bao giờ là khối lượng tài liệu khổng lồ. Xin đừng rơi vào cái bẫy của việc sinh ra tài liệu qui trình  để đạt tới mức trưởng thành CMMI vô nghĩa. Không tổ chức nào đã bao giờ đạt tới bất kì mức nào bằng việc sinh ra giấy tờ vì điều đó chẳng có nghĩa gì. Cải tiến yêu cầu tổ chức sửa chữa các vấn đề quản lí dự án – lập kế hoạch, ước lượng, theo dõi – và dứt khoát không sinh ra nhiều giấy tờ.

Hỏi: Tôi bị thuyết phục rằng thay đổi là vấn đề kĩ thuật và những người kĩ thuật – người hiểu nó – phải làm nó. Là người quản lí, vai trò của tôi là không chen vào cách của họ, nhưng trao quyền cho họ làm bất kì cái gì họ thấy cần làm. Thầy nghĩ gì?

Đáp: Ngược lại, tôi mạnh mẽ tin tưởng rằng thay đổi là vấn đề quản lí, không phải là vấn đề kĩ thuật. Tôi tin tưởng quản lí cần hội tụ vào các mục tiêu doanh nghiệp cần thay đổi như giảm thời gian chu kì, giảm chi phí, tăng chất lượng và ra quyết định về cách hoàn thành các mục tiêu đó. Cấp quản lí phải giữ vai trò tích cực trong cam kết thay đổi và hỗ trợ thay đổi khi nó xảy ra, điều phối và quản lí qui trình thay đổi, và bám theo quyết định rằng thay đổi là quan trọng cho doanh nghiệp. Nhớ “Thay đổi là không tránh khỏi, tồn tại là tuỳ chọn.” Dừng tranh cãi liệu thay đổi là vấn đề quản lí hay vấn đề kĩ thuật đi mà hiểu rằng thay đổi là vấn đề kinh doanh mà mọi nhà quản lí đều cần quản lí.

Hỏi: Tại sao chúng ta tuân theo khuôn khổ CMMI? Cái gì là khác biệt giữa khuôn khổ này và các khuôn khổ khác như khuôn khổ kiến trúc của Zachman?

Đáp: CMMI là khuôn khổ cho cải tiến qui trình phần mềm. Nó đã được dùng trong toàn ngành công nghiệp với nhiều thành công. Việc chấp nhận khuôn khổ này cũng là kì lạ, cả từ quan điểm của cấp quản lí và người hành nghề. CMMI đại diện cho khuôn khổ đầy đủ với các định nghĩa và ví dụ bao quát lập kế hoạch, thiết kế, và khía cạnh quản lí phần mềm. Nó cũng gợi ý một trình tự mà một tổ chức có thể theo để cải tiến qui trình phần mềm của mình. Nó cung cấp cách đo để điều phối qui trình triển khai và phần lớn trong tất cả, nó mang nghĩa thông thường thuần tuý.

Khuôn khổ kiến trúc Zachman là công cụ để mô tả các khía cạnh khác hay cách nhìn về hệ thống phần mềm nhưng không phải là khuôn khổ để cải tiến qui trình phần mềm.

Hỏi: Một tổ chức cần bao nhiêu độ đo để đạt tới CMM mức 2? Chúng tôi có thể tìm nó ở đâu?

Đáp: Theo ý kiến của tôi nhiều tổ chức đã có cách đo và độ đo cần cho CMMI mức 2 như Khiếm khuyết, Kích cỡ, Thời gian và Chi phí nhưng những dữ liệu này phải được phân tích và sử dụng. Đã tiến hành hàng trăm việc đánh giá, tôi thấy phần lớn các tổ chức đã tràn ngập khối lượng dữ liệu những chưa bao giờ được người quản lí dự án dùng.

Hỏi: Thầy đổi người thế nào? Sao người làm phần mềm bao giờ cũng cư xử theo cách họ làm?

Đáp: Hành vi con người được xác định bởi niềm tin (điều họ cảm thấy chắc chắn) và giá trị (điều họ coi là quan trọng nhất). Dưa trên định nghĩa này, người làm phần mềm không khác bất kì ai khác.

Niềm tin được tạo nên từ kinh nghiệm trước đây và thông tin nhận được. Giá trị là điều cá nhân coi là quan trọng trong cuộc sống của họ. Để thay đổi hành vi của một người, người ta cần hiểu giá trị và niềm tin cái gây ra hành vi. Bạn có thể giúp sửa bất kì niềm tin nào dựa trên thông tin sai – huấn luyện và giáo dục thực sự giúp ích và trao đổi cũng vậy. Bạn cũng có thể trắc nghiệm ưu tiên giá trị của một người và hậu quả của hành vi kết quả – thưởng và phạt giúp điều này và hướng dẫn và huấn luyện cũng giúp cho điều này).

Hỏi: Cấp quản lí của tôi không tin phần mềm là quan trọng và do đó không cam kết cải tiến. Tôi có thể làm gì để thuyết phục họ rằng phần mềm là quan trọng?

Đáp: Bạn có thể nhắc nhở người quản lí của bạn rằng phần mềm điều khiển sản phẩm của bạn. Nó tới với khiếm khuyết và để cải tiến sản phẩm, tổ chức cần hội tụ vào qui trình tạo ra sản phẩm. Chất lượng sản phẩm của bạn trực tiếp ảnh hưởng tới tuyến đáy của tổ chức của bạn và chừng nào tuyến đáy mà không quan trọng, tổ chức của bạn phải nhìn vào phần mềm như một trong các nhân tố quan trọng cần cải tiến. Theo cách này, tổ chức của bạn sẽ không bao giờ thay đổi trừ phi văn hoá của tổ chức thay đổi và mọi thay đổi phải bắt đầu từ trên đỉnh – người quản lí.

Hỏi: Thầy cải tiến phần mềm thế nào khi những người thực hiện nó thuộc vào vài nhóm và từng nhóm đều có phần hành động?

Đáp: Các nhà chuyên môn phần mềm từ lâu đã tham gia vào trong tranh luận về qui trình phần mềm và người thực hiện chúng. Người thu thập yêu cầu, người thiết kế, người phát triển và người kiểm thử thường xuyên dường như có mối quan hệ đối địch, mặc dầu họ tất cả đều có chung cùng mục đích – sản phẩm phần mềm chất lượng cao. Nhóm của họ hình thành tốt thế nào cũng không thành vấn đề, các qui trình không thể nào thành công nếu các thành viên không hoà thuận với nhau.

Hỏi: Đặc trưng của việc là người quản lí giỏi cho cải tiến qui trình là gì?

Đáp: Người quản lí giỏi cho cải tiến qui trình bao giờ cũng:

  • Có ý thức về chủ định, biết mục đích và mục tiêu và chủ định của cải tiến.

  • Làm cho mọi sự vận động và làm mọi sự xảy ra.

  • Cho chỉ đạo rõ ràng về cách tổ chức sẽ cải tiến và không làm những điều nào đó là tuỳ chọn.

  • Lập kế hoạch và theo dõi để đảm bảo mọi thứ xảy ra.

  • Điều phối các hoạt động để xem liệu có gì sai lệch, làm hành động sửa chữa.

  • Nhấn mạnh vào dữ liệu cải tiến, thừa nhận người lãnh đạo và người đóng góp trong tổ chức.

Hỏi: Rủi ro phần mềm và quản lí rủi ro là gì?

Đáp:  Rủi ro là các biến cố tương lai với xác suất xuất hiện và tiềm năng tổn thất. Nhiều vấn đề nảy sinh trong nỗ lực phát triển phần mềm đầu tiên được biết tới như rủi ro bởi ai đó trong dự án. Được phát hiện đúng lúc, rủi ro có thể được tránh, được khử bỏ, hay có tác động bị giảm nhẹ. Vấn đề là rủi ro có thời điểm xảy ra. Hay cách khác để nhìn vào nó – mọi vấn để xuất hiện trong dự án phát triển phần mềm đều có rủi ro vào một lúc nào đó.

Quản lí rủi ro phần mềm là kĩ thuật dựa trên khái niệm về giảm thiểu rủi ro bằng việc hỏi các câu hỏi nền tảng:

1.      Xác suất – khả năng vấn đề sẽ xuất hiện là gì?

2.      Tác động – vấn đề sẽ gây tốn kém bao nhiêu nếu nó xuất hiện?

3.      Khung thời gian – vấn đề có thể xuất hiện khi nào?

Quản lí rủi ro phần mềm nhận diện rủi ro, phân tích nó, trao đổi nó với mọi người trong tổ chức và đi tới giải pháp khử bỏ hay giảm nhẹ rủi ro. Một lần nữa, tại sao chúng ta cần quản lí rủi ro? Được phát hiện đúng lúc, rủi ro có thể được tránh, được khử bỏ, hay có tác động của nó được làm nhẹ đi.

English version

CMMI-15

Question: Our organization would like to conduct an appraisal to determine where we are in the CMMI maturity levels. What are the steps and issues?

Answer: Following are the steps in a typical appraisal:

1.      Determine the scope, improvement goals and establish sponsorship.

2.      Establish implementation infrastructure (SEPG)

3.      Plan appraisal details.

4.      Prepare and train an appraisal team.

5.      Brief appraisal participants. (Software projects members)

6.      Administer CMMI questionnaires.

7.      Analyze questionnaire responses.

8.      Review artifacts and documents.

9.      Conduct interviews with functional area representatives (SQA, CM).

10. Conduct interviews with managers, practitioners, project leads.

11. Consolidate data obtained from the questionnaire, reviews and interviews.

12. Establish findings and recommendations.

13. Determine maturity level.

14. Brief sponsor on appraisal results.

15. Brief appraisal participants on results.

16. Brief organization on appraisal results.

17. Prepare appraisal final report.

The appraisal should be conducted by a SEI qualified appraiser and based on the principle of confidentiality. The accuracy and usefulness of the results is critically dependent upon everyone’s ability to speak freely and without fear of retribution. An unqualified consultant can confuse people, set wrong expectations, and lead the organization down the wrong path with promises but not kept and eventually improvement failure.

Question: Why is the SEPG also responsible for technology transfer in an organization? Why not assign other technical people to do this task?

Answer: When a new software technology is introduced into an organization, significant changes need to take place in that organization to ensure successful adoption. This is true whether the technology is a process (such as Reviews), a discipline (such as Project Management) or a tool (such as RUP).

In the past, teams responsible for introducing new technologies to the organization often were technical people but many technology transfers have failed. Based on data collected I found that most failures are not the technology or the process but the lack of instruction and training skills in the people responsible for making change happen. Most have technical skills but not the necessary skills to plan and implement a successful technology transfer.

SEPG members are technical professionals, trained to introduce changes in an organization and very familiar with the “change process”. Therefore, they are the most likely to be assigned as the “change agents” responsible for technology transfer in an organization.

Question: What is the definition of a “good” software engineering team? Do software people must work in “team”?

Answer: Your question makes me think of a meeting I had with a group of software people from a company. They said that a “good software team” is one that is made up of good people—the definition of “good people” being them and only them.

A “good” software engineering team can be difficult to define because of some issues such as differences in background and style as well as an individual sense of “being highly creative” or “better” than someone else. However, with the introduction of software engineering disciplines, the days of the “self centered” are gone. I have known many good software teams where people are mature, professional, and willing to share their knowledge with each other. Good teams require a mixture of skills that complement one another in order to achieve common goals. That applies to any team and software is no different.

Question: What do you consider a successful project? What are the critical factors?

Answer: A project is considered a success only if the cost, schedule, and quality objectives are met. The critical factor in a project is the estimation process which helps project managers in managing and controlling the project costs and in scheduling to achieve the required functionality. Project managers should only commit to a project when they have a cost and schedule estimate for which they have a certain level of confidence.

No single standard estimating method is suited for every type of project. Each organization needs to define an estimating process suited to its own needs.

Some items to consider when defining your estimating process include:

  • When are estimates and re-estimates performed?
  • Who performs the estimates?
  • What specifically is estimated, e.g. effort, loading, software, size, etc.?
  • How are estimates monitored and controlled?
  • If there is discrepancy between the actual and the estimate, when do you re-estimate?
  • What happens when the estimate is not accepted by management? by the customer?
  • If requirements change when would you re-estimate?
  • When wouldn’t you re-estimate?
  • What measures of previous projects (project metrics, process metrics) are recorded in an organization database?
  • How are measures of previous projects maintained to improve software cost estimates?

Question: Why are people wasting time learning process improvement skills when they could learn other skills such as JAVA, C++, and OOD to make more money and have better employment opportunities?

Answer: Software Process Improvement skills get less attention than the so-called “technical” skills such as C++, JAVA, network integration, and OOD. Yet as more organizations seek to improve their competitive position through better software processes, the need for skilled process improvement professionals is also growing. There is a growing interest in software process improvement all over the world. The demand for this professional is growing faster than the demand for so called “technical skills” with job offers at much higher salaries than other fields. Anyone can learn JAVA and C++ in school but there is no school teaching the skill of process improvement yet. You have to practice it and learn it.

Question: A consultant advised us to document everything so we can achieve CMMI level 3. It seems like everybody is rushing to write process documentation now. Is this what process improvement is all about?

Answer: Software process improvement is defined as “activities that improve organization software processes to achieve a specific result.” The end result may be a reduction in cost, defects, and cycle time but never a huge volume of documentation. Please do not fall into the trap of generating process documentation to achieve a meaningless CMMI maturity level. No organization ever achieved any level by generating paper since it does not make any sense. Improvement requires an organization to fix project management issues—planning, estimating, tracking—and it is definitely not generating more paper.

Question:  I am convinced that change is a technical issue and technical people—people who understand it—must do it. As a manager, my role is not getting in their way, but empowering them to do whatever they need to do. What do you think?

Answer: On the contrary, I strongly believe that change is a management issue, not a technical issue. I believe management needs to focus on the business objectives of change such as reducing cycle time, reducing costs, increasing quality and making decisions about how to accomplish those objectives. Management should take an active role in commitment to change and supporting change as it goes, monitoring and managing the change process, and sticking with the decision that change is important to the business. Remember “Change is inevitable, survival is optional.” Stop debating whether change is a management issue or a technical issue rather understand that change is a business issue that every manager needs to manage.

Question: Why do we follow the CMMI framework? What is the difference between this framework and others such as the Zachman’s architecture framework?

Answer: The CMMI is a framework for software process improvement. It has been used throughout the industry with a lot of success. The acceptance of this framework is also phenomenal, both from the management and practitioner viewpoints. The CMMI represents a complete framework with definitions and examples that cover the planning, design, and management aspect of software. It also suggests a sequence which an organization can follow to improve its software processes. It offers measurements to monitor the deployment process and most of all, it is purely common sense.

Zachman’s architecture framework is a tool to describe different aspects or views of a software system but not a framework to improve the software process.

Question: How many measurements does an organization need to achieve CMM level 2? Where do we find them?

Answer: In my opinion many organizations already have metrics and measurements needed for CMMI level 2 such as Defects, Size, Time and Cost but these data must be analyzed and used. Having conducted hundreds of appraisals , I found that most organizations already had an overwhelming amount of data collected but never used by project managers.

Question: How do you change people? Why do software people always behave the way they do?

Answer: A person’s behavior is determined by beliefs (what they feel certain about) and values (what they consider most important). Based on this definition, software people are not different from anyone else.

Beliefs are formed from previous experiences and information received. Values are what individuals consider important in their life. To change the behavior of a person, one needs to understand the values and beliefs that are causing the behavior. You could help to correct any beliefs that are based on false information—training and education really helps and so does communication. You could also verify the person’s value priorities and the consequences of the resulting behaviors—reward and punishment helps and so does mentoring and coaching).

Question: My management does not believe software is important and therefore is not committed to improvement. What can I do to convince them that software is important?

Answer: You may want to remind your manager that software drives your products. It comes with defects and in order to improve your products, the organization needs to focus on the process that creates your products. Your products’ quality directly affects your organization’s bottom line and unless the bottom line is not important, your organization must look at software as one of the important factors to improve. By the way, your organization will never change unless the organization’s culture changes and every change begins with the one on top—the manager.

Question: How do you improve software when the people who implement it belong to several groups and each has a piece of the action?

Answer: Software professionals have long been engaged in debate over software processes and the people who implement them. Requirements gathering people, designers, developers and testers frequently seem to have adversarial relationships, although they all share the same goal—a high-quality software product. No matter how well their group performs, the processes are unlikely to succeed if the participants fail to get along.

Question: What are characteristics of being a good manager for process improvement?

Answer: A good manager for process improvement always:

  • Has a sense of purpose, know the goals and objectives and purpose of improvement.
  • Gets things moving and make things happen.
  • Give clear direction on how the organization is going to improve and doesn’t make certain things optional,
  • Plans and follows up to make sure things happen.
  • Monitoring activities to see if there is any deviations, takes corrective actions.
  • Insists on improvement data, recognizes leaders and contributors within the organization.

Question: What are software risks and risk management?

Answer: Risks are future events with a probability of occurrence and a potential for loss. Many of the problems that arise in software development efforts were first known as risks by someone in the project. Upon timely discovery, risks can be avoided, eliminated, or have their impacts lessened. A problem is a risk whose time has come. Or another way of looking at it—every problem that occurs in a software development project was a risk at one time.

Software risk management is a technique that is based on the concept of mitigating risks by asking the fundamental questions:

1.      Probability—what is the likelihood that a problem will occur?

2.      Impact—how much will the problem cost if it does occur?

3.      Time frame—when is the problem likely to occur?

Software risk management identifies the risk, analyzes it, communicates it to everybody within the organization and comes up with a solution to eliminate or reduce the risk. Once again, why do we need risk management? Upon timely discovery, risks can be avoided, eliminated, or have their impacts lessened.

 


Gửi bình luận
(0) Bình luận
1

CMMI-37

Hỏi: Trong nhiều năm, phần mềm bao giờ cũng bị trách cứ vì mọi sự đi sai. “Căn nguyên” của phần lớn thất bại phần mềm là gì và làm sao cải tiến nó?
2

CMMI-36

36.01 Hỏi: SEPG hay người hành nghề phần mềm có phải tạo ra Qui trình phần mềm chuẩn của tổ chức Organization Standard Software Process (OSSP) không? Ai nên làm cho nó có hiệu lực, người quản lí hay SEPG?
3

CMMI-38

Hỏi: Năng lực lõi là gì? Tại sao nó là quan trọng cho tổ chức?
4

Mối quan tâm khác với CMMI

Một người quản lí dự án viết cho tôi: “Tôi không biết gì về CMMI, tôi lo lắng rằng chúng tôi có thể không đạt tới Mức 3. Xin thầy lời khuyên.”
5

Cải tiến qui trình với CMMI

Làm sao để bắt đầu cải tiến qui trình dùng CMMI? Phải mất bao lâu để chuyển lên một mức CMMI? Xin thầy lời khuyên.”

CMMI-14

Nguồn của rủi ro phần mềm là gì? Tại sao mọi người không thích nói về nó?

CMMI-13

Hỏi: Tôi tin chúng ta nên học từ các công ti khác đã từng làm cải tiến qui trình. Họ có công bố các bài học rút ra của họ không?

CMMI-12

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ọ?

CMMI-11

Hỏi: Khác biệt giữa tổ chức phần mềm tốt nhất và tồi nhất là gì? Chúng ta có dữ liệu nào không?

CMMI-10

Hỏi: Xin thầy nói thêm cho tôi về khuôn khổ CMMI. Nó là gì và làm sao nó được coi là chuẩn để đo chất lượng?

Cải tiến theo CMMI

Để cải tiến qui trình bằng việc dùng CMMI: Bạn cần định nghĩa qui trình để thu thập dữ liệu đo ở mức dự án, mức tổ chức (DTT) và gióng thẳng chúng với việc kinh doanh của DTT (Mục đích & Mục tiêu).

CMMI

Vì công ti bạn xác định qui trình chuẩn dựa trên khuôn khổ CMMI để cải tiến, sau đây là một số gợi ý:

CMMI 1 tới 3

Hỏi: Công ti chúng tôi là công ti CMMI mức 1 nhưng cấp quản lí đã quyết định mua qui trình phần mềm từ một tổ chức đã được thẩm định ở mức 3 và huấn luyện cho tất cả mọi người tuân theo qui trình đó.

Mối quan tâm khác với CMMI

Blog GS John VU - GS John Vu - 16/06/2024 12:00
Một người quản lí dự án viết cho tôi: “Tôi không biết gì về CMMI, tôi lo lắng rằng chúng tôi có thể không đạt tới Mức 3. Xin thầy lời khuyên.”

2 cao thủ gây tiếc nuối trong truyện của Kim Dung: Nếu tham gia Hoa Sơn luận kiếm có thể đã chiến thắng

Thư giãn - Nguyệt Phạm - 16/06/2024 11:00
Kết quả của kỳ Hoa Sơn luận kiếm lần thứ nhất có thể đã khác nếu 2 đại cao thủ này tham gia tỉ thí.

Câu chuyện xúc động về người cha, nghệ sĩ Quốc Tuấn và cậu bé Bôm sau 7 năm

Truyền cảm hứng - Nguyệt - 16/06/2024 10:00
Câu chuyện xúc động về tình phụ tử thiêng liêng giữa diễn viên Quốc Tuấn và Bôm - con trai anh, từng gây bão tại chương trình Điều ước thứ bảy năm 2017, từ đó truyền cảm hứng cho nhiều khán giả.

Bạn đang nghịch gì với đời mình - Hiểu biết chính mình là một tiến trình

Từ sách - Phim - YÊN VŨ - 16/06/2024 09:00
Theo Krishnamurti, hiểu biết chính mình là một tiến trình mà ở đó ta khám phá và nhận biết về bản thân qua hành động, qua các mối tương quan với xã hội và với người khác.

Hạnh phúc đến từ sự biến mất - Được mất chỉ là lẽ thường

Từ sách - Phim - Quìn - 16/06/2024 08:00
Cánh cửa hạnh phúc luôn mở rộng. Chỉ cần chúng ta hướng tâm bình an trên mỗi bước đi, hạnh phúc sẽ hóa nhiệm màu ngay trước mắt.

Cải tiến qui trình với CMMI

Blog GS John VU - GS John Vu - 15/06/2024 12:00
Làm sao để bắt đầu cải tiến qui trình dùng CMMI? Phải mất bao lâu để chuyển lên một mức CMMI? Xin thầy lời khuyên.”

5 điều giúp tôi trị căn bệnh 'thích giày vò chính mình'

Suy ngẫm - Trung Hạ - 15/06/2024 11:00
Quá trình cải thiện chính mình không hề đơn giản, song không vì thế mà bỏ cuộc.

Cái bẫy 'vì hạnh phúc' của những cặp bố mẹ có con khi còn quá trẻ

Phong cách sống - Hải Yến - 15/06/2024 10:00
Yêu nhau, cặp đôi muốn tiến đến giai đoạn khẳng định tình cảm bằng một đứa con chung. Song, tình yêu của vợ chồng trẻ sẽ bị bóp méo thành hình dạng nào dưới những áp lực nuôi con nếu ông bố, bà mẹ chưa hiểu rõ những đòi hỏi của thiên chức này?

Thánh kinh marketing - Chừng nào chưa phải là một thương hiệu, chừng đó bạn còn chật vật kiếm tiền

Từ sách - Phim - YÊN VŨ - 15/06/2024 09:00
Nếu là một người lao động đơn thuần, khách hàng không quan tâm đến người cung cấp dịch vụ mà chỉ chú trọng giá tiền. Nhưng nếu là một chuyên gia, bạn có thể dễ dàng đòi giá cao và giá trị thị trường của bạn cũng sẽ cao.

Hiểu - Osho: Chỉ khi đã giàu có, mới nhận thức được sự nghèo khó bên trong của mình

Từ sách - Phim - Quìn - 15/06/2024 08:00
Tình trạng mất cân bằng nghiêm trọng đã xảy ra. Sự giàu có ở đó, nhưng con người không hề cảm thấy giàu có, phong phú; ngược lại, họ đang cảm thấy rất bần cùng, rất nghèo khổ.

Cuộc hành trình CMMI

Blog GS John VU - GS John Vu - 14/06/2024 12:00
Tôi đã nhận được nhiều email hỏi về việc dùng CMMI cho cải tiến qui trình. Tôi đã viết nhiều bài trên website này, cho nên xin xem lại chúng. Khi mọi người nghĩ về cải tiến qui trình, họ phải cân nhắc ba cấu phần: qui trình, con người và công cụ.

Cao thủ kỳ lạ trong truyện của Kim Dung: Ra đòn mắt thường không thể thấy, chết vì lý do lãng xẹt

Thư giãn - Nguyệt Phạm - 14/06/2024 11:00
Một mình nhân vật này có thể đánh bại 5 đại cao thủ.

Nghệ sĩ Quốc Tuấn xúc động khi bé Bôm tốt nghiệp hệ trung cấp tại Học viện Âm nhạc Quốc gia Việt Nam

Truyền cảm hứng - Nam An - CFB - 14/06/2024 10:00
Sau hơn 20 năm cùng con chiến đấu để chữa căn bệnh hiếm gặp, giờ đây nhìn Bôm trưởng thành, tự lập và được sống hết mình với đam mê âm nhạc, anh Tuấn cười mãn nguyện và hạnh phúc.

Bạn đang nghịch gì với đời mình - Chỉ những ai chưa biết đến tình yêu thương mới đặt ra câu hỏi về mục đích cuộc sống

Từ sách - Phim - Quang Thanh - 14/06/2024 09:00
Nếu quan sát bản thân một cách kỹ càng, bạn sẽ thấy rằng thực ra chúng ta chẳng làm gì ngoài việc theo sau người khác; và cái quá trình theo gót này được ta gọi là “sống”; sau tất cả, vào thời điểm sự sống kết thúc bạn sẽ tự hỏi: “Ý nghĩa của cuộc sống là gì?”.

Sức mạnh của sự trầm lắng - 5 bí quyết tránh xao lãng khi đang lắng nghe

Từ sách - Phim - Quìn - 14/06/2024 08:00
Mặc dù người hướng nội có khuynh hướng lắng nghe thấu đáo hơn người hướng ngoại, nhưng đôi lúc bạn vẫn dễ dàng mất tập trung khi phải lắng nghe trong một khoảng thời gian dài.
HẠT GIỐNG TÂM HỒN
  • Địa chỉ: 11H Nguyễn Thị Minh Khai - P. Bến Nghé - Quận 1 - TP. Hồ Chí Minh
  • Điện thoại: (+8428) 38233860 - Email: triviet@firstnews.com.vn
  • Giấy phép số 496/GP-BTTTT Bộ Thông tin và Truyền thông cấp ngày 17/10/2022
  • Chịu trách nhiệm chính: Nguyễn Văn Phước
  • Công ty TNHH văn hóa sáng tạo Trí Việt
  • Fax: (+8428) 38224560
  • Thỏa thuận cung cấp dịch vụ mạng xã hội Hạt giống tâm hồn
2019 Bản quyền thuộc về hatgiongtamhon.com.vn. Phát triển bởi ONECMS
Thứ 2, 17/06/2024