Đáp: Có nhiều lí do cho thất bại phần mềm, sau đây là năm lí do hàng đầu được nhận diện bởi người phát triển phần mềm và người quản lí trong cuộc điều tra được tiến hành tại Đại học Carnegie Mellon:
Người phát triển phần mềm không hiểu nhu cầu của khách hàng. Họ hội tụ vào lập trình và không bận tâm thảo luận yêu cầu với khách hàng. Họ vội vàng bỏ qua pha lập kế hoạch và thiết kế để vào lập trình bởi vì đó là kĩ năng họ được dạy trong chương trình Khoa học máy tính. Thái độ “mã trước, lập kế hoạch và hỏi câu hỏi sau” là lí do số một cho thất bại dự án. Về căn bản, khi được kết thúc người phát triển mới thấy ra rằng điều họ xây ra không phải là điều khách hàng muốn.
Người quản lí dự án không có kĩ năng hay huấn luyện để ước lượng tài nguyên, thời gian, kích cỡ và phạm vi của dự án. Phần lớn những người quản lí ước lượng thấp các nhân tố này nên gây cho dự án bị chậm, và tốn nhiều hơn. Bởi vì phần lớn các dự án đều chậm, nhiều người bỏ qua pha kiểm thử cho nên phần mềm của họ đầy lỗi, điều đến lượt nó làm tốn kém thêm để sửa.
Các thành viên tổ dự án không được huấn luyện tốt về phương pháp phần mềm, họ không biết cách kiểm soát thay đổi phần mềm, mất kiểm soát phiên bản phần mềm làm nảy sinh các vấn đề tích hợp và kiểm thử, mà điều này đến lượt nó lại tạo ra sản phẩm chất lượng thấp.
Người quản lí dự án quyết định chuyển công cụ phát triển vào giữa dự án tạo ra lẫn lộn trong các thành viên tổ dự án, rồi thêm nhiều người để “tăng tốc mọi thứ” để đáp ứng yêu cầu lịch biểu, điều này đến lượt nó lại tạo ra nhiều lẫn lộn hơn và góp phần vào thất bại dự án.
Những giờ làm việc dài tạo ra căng thẳng cho người phát triển cho nên họ bỏ qua vài bước như kiểm thử hay kiểm điểm để đối phó, điều gây ra kết quả có nhiều lỗi. Các thành viên tổ bắt đầu tranh cãi và giữ thông tin riêng cho mình, điều tạo ra những vấn đề cá nhân nhiều hơn cho dự án.
Hỏi: Làm sao tôi có thể ước lượng được kích cỡ phần mềm sớm trong dự án, vì số dòng mã không phải là chọn lựa tốt và khó ước lượng?
Đáp: Bạn có thể xem xét việc dùng điểm chức năng, một cách đo suy dẫn về kích cỡ chương trình, có thể được dùng trong ước lượng sớm. Không giống như dòng mã, điểm chức năng có thể được suy dẫn ra từ đặc tả chức năng hay từ thiết kế mức đỉnh. Để đi tới ước lượng nhất quán, tập các “qui tắc đếm” đã được Nhóm người dùng điểm chức năng quốc tế (IFPUG) lập công thức.
Hỏi: Có thể ước lượng chi phí phần mềm sớm trong dự án không? Hay tốt hơn nên đợi đến lúc cuối trong dự án khi chúng ta biết nhiều hơn về dự án?
Đáp: Điều rất quan trọng là ước lượng kích cỡ, tài nguyên, lịch biểu và chi phí dự án sớm nhất có thể được và điều chỉnh chúng tương ứng khi chúng ta biết nhiều hơn về các yêu cầu.
Nhiều năm trước, chi phí phần mềm chỉ chiếm số phần trăm nhỏ của chi phí toàn thể hệ thống tính toán và mọi người bỏ qua nó. Ngày nay nó là yếu tố tốn kém nhất trong mọi hệ thống. Ước lượng nhầm chi phí phần mềm có thể tạo ra chênh lệch giữa lợi nhuận và tổn thất. Hiện thời, chi phí phần mềm bị thấu chi là vấn đề chung trong mọi tổ chức phần mềm bởi vì nhiều người vẫn không chú ý tới nó hay không biết cách. Mặc dầu chi phí phần mềm rất khó tính toán vì nó bao gồm nhiều biến – kĩ thuật, môi trường, chính trị, con người – nó vẫn có thể được thực hiện bằng các kĩ thuật phân rã.
Hỏi: Tại sao người làm phần mềm cần huấn luyện? Các công cụ tự động không được thiết kế để cải tiến năng suất và chất lượng sao?
Đáp: Công cụ của bạn tốt đến đâu cũng không thành vấn đề, bạn vẫn phải dựa vào con người. Thái độ và sự tham gia của cán bộ là những nhân tố mấu chốt trong việc xác định ra hiệu năng toàn thể của bất kì sản phẩm phần mềm nào. Sản phẩm phần mềm chất lượng được tạo ra do những người quản lí hiểu nhu cầu của các thành viên tổ và giúp họ hiện thực tiềm năng đầy đủ của họ bằng việc giáo dục, huấn luyện có hiệu quả và nhận biết. Công cụ tất yếu sẽ theo sau. Rất thường là các tổ chức đều muốn tìm kiếm cải tiến chỉ qua phát triển các công cụ tự động và rồi họ ngạc nhiên khi các “giải pháp” này không có tác dụng. Công cụ là tốt khi mọi người dùng nó – cùng điều đó cũng áp dụng cho phương pháp luận. Không có huấn luyện thích hợp, chẳng cái gì sẽ có tác dụng tốt.
Hỏi: Tại sao dùng lại phần mềm không được biện hộ như một phần của cải tiến qui trình?
Đáp: Dùng lại phần mềm là một trong những kĩ thuật tốt nhất để làm tăng chất lượng và năng suất phần mềm. Tuy nhiên, khái niệm về cấu phần phần mềm dùng lại và qui trình dùng các cấu phần này để xây dựng hệ thống còn chưa được hiểu rõ.
Phần mềm dùng lại có thể được định nghĩa là cấu phần phần mềm dựng sẵn mà đã được thiết kế tường minh để được dùng trong nhiều ứng dụng, nói chung là bên trong một miền ứng dụng đã xác định. Các cấu phần dùng lại được có thể bao gồm các đặc tả yêu cầu, thông tin thiết kế, mã nguồn và trường hợp kiểm thử. Cách tiếp cận không thể thức hiện thời tới việc xây dựng cấu phần dùng lại, dù nó có thể là bất kì cái gì – chỉ là làm ra nó và mọi người sẽ dùng nó – là không đủ tốt, bởi vì những cấu phần như vậy rất có thể sẽ bị quên lãng trong kho.
Tôi tin để làm cho phần mềm dùng lại có hiệu quả, tổ chức phải tạo ra qui trình được xác định tốt về việc dùng các cấu phần dùng lại được. Các cấu phần phải được thiết kế tường minh với việc dùng lại được tính tới trong tâm trí, không phải là bất kì cái gì mọi người có thể vớ được và dùng. Qui trình dùng lại phải được thiết kế cho việc dùng có hệ thống thay vì việc dùng theo cơ hội. Điều đó có nghĩa là mọi cấu phần dùng lại được phải được kiểm thử kĩ lưỡng và được dùng theo các qui trình và hướng dẫn đã xác định. Việc tiết kiệm phần mềm dùng lại được không phải là tiết kiệm thời gian phát triển mà là tiết kiệm thời gian kiểm thử và tích hợp.
Tôi bao giờ cũng biện hộ cho việc dùng lại phần mềm như một phần của cải tiến qui trình nhưng năng lực của tổ chức để áp dụng khái niệm này cũng rất quan trọng. Tại CMMI mức 1 và CMMI mức 2 tổ chức quá bận rộn với các vấn đề khác cho nên họ không thể thực hiện được dùng lại có hiệu quả. CMMI mức 3 hay CMMI mức 4 vững chắc là nơi dùng lại có thể có hiệu quả.
Hỏi: Thầy có khuyến cáo về các chuẩn của Viện quản lí dự án (PMI) không?
Đáp: Cuốn Hướng dẫn về Thân tri thức quản lí dự án của Viện quản lí dự án làm tài liệu cho nhiều thực hành về quản lí dự án. Nó được viết tốt và được coi như chuẩn quản lí dự án rất tốt được quốc tế thừa nhận. Tuy nhiên, nó được viết cho tất cả các môn quản lí dự án, từ kĩ nghệ dân sự tới chế tạo và nó rất toàn diện. Bạn cần dành thời gian và huấn luyện để được lợi từ việc dùng nó vì một số những sáng suốt có giá trị nhất trong quản lí dự án vẫn bị chôn vùi trong phong cách giản lược của tài liệu này. Tôi đã dùng chuẩn này trong nhiều năm và thấy nó có giá trị và tôi không thấy vấn đề gì trong việc dùng các chuẩn PMI vì việc quản lí dự án tốt là nền tảng cho bất kì dự án nào. Tôi tin mọi thành viên cải tiến qui trình nên quen thuộc với chuẩn quản lí dự án này.
Hỏi: Hệ thống mở là gì? Sao có nhiều định nghĩa thế về hệ thống mở?
Đáp: Có nhiều cách nhìn và định nghĩa về hệ thống mở. Tôi tin hệ thống mở là hệ thống thực hiện đặc tả mở đủ cho giao diện, dịch vụ và dạng thức hỗ trợ. Điều này sẽ tạo khả năng cho các cấu phần được chế tạo đúng để được dùng trong miền rộng các hệ thống với thay đổi tối thiểu.
Để làm điều này, hệ thống phải:
1. Được xác định tốt, được dùng rộng, và là giao diện/giao thức không sở hữu riêng.
2. Dùng các chuẩn được phát triển bởi các tổ chức tiêu chuẩn được công nghiệp thừa nhận (như IEEE, ISO).
3. Xác định tất cả các khía cạnh của giao diện hệ thống để tạo điều kiện cho các khả năng hệ thống mới hay phụ thêm cho một miền rộng các ứng dụng.
4. Cung cấp tường minh việc mở rộng hay nâng cấp qua việc tổ hợp các yếu tố hiệu năng phụ với tác động tối thiểu lên hệ thống.
Hỏi: Là người dùng sản phẩm phần mềm, tôi không hài lòng khi tôi đọc thấy nói những người làm phần mềm phàn nàn về họ việc thiếu tri thức về người dùng và không có khả năng quyết định. Tôi nghĩ người làm phần mềm làm việc kém khi hiểu nhu cầu của tôi, cho tôi điều tôi cần đúng hạn và trong ngân sách, và cung cấp chất lượng cao. Họ có quên ai đang trả hoá đơn của họ ở đây không?
Đáp: Khách hàng có xu hướng tin người làm phần mềm không hiểu nhu cầu của họ còn người phát triển phần mềm bao giờ cũng tin khách hàng không biết điều họ muốn. Tại sao chúng ta cứ tiếp tục có thái độ “chúng ta đối với họ” thay vì cùng làm việc với nhau như một tổ để xây dựng hệ thống tốt hơn? Làm sao chúng ta có thể tiếp tục xác định được vị thế của riêng mình và không trao đổi lẫn nhau? Nhớ mục đích là xây dựng sản phẩm chất lượng cao.
Tôi tin người dùng tối thượng là người dùng mua sản phẩm và họ quan tâm về chất lượng, chi phí, và thời gian ra thị trường. Họ biết rằng họ có chọn lựa về sản phẩm nào họ muốn mua và họ muốn mua nó từ công ti nào.
Hỏi: Là người quản lí, mức độ trưởng thành là rất quan trọng với tôi vì nó là quan trọng cho công ti của tôi. Chúng tôi được thẩm định ở CMMI mức 1 và có kế hoạch để đạt tới CMMI mức 2 trong 12 tháng tới. Tôi cam kết hoàn toàn để làm điều đó cho đúng và sẽ làm mọi điều. Thầy có lời khuyên nào không?
Đáp: Nếu mức độ trưởng thành CMMI là mục đích duy nhất quan trọng cho bạn, thì có vài điều tổ chức của bạn có thể làm:
1. Việc cải tiến sẽ được tiến hành bởi những người làm việc này trong tổ chức, điều có nghĩa là mọi người trong tổ chức của bạn phải tham gia vào việc triển khai các nhiệm vụ cải tiến qui trình nào đó.
2. Mọi người sẽ được phân công vào các tổ tương ứng với mối quan tâm và tri thức chuyên gia của họ và người quản lí sẽ được phân công làm huấn luyện viên cho tổ.
3. Các giải pháp mới được xác định bởi tổ cải tiến phải được cấp quản lí kiểm điểm và khi được chấp nhận, mọi người phải được huấn luyện để tuân theo chúng.
4. Giải pháp phải được thực hiện theo các pha nhỏ, không tất cả ngay một lúc, như đã được nói tới trong các blog khác: Xác định, Thử nghiệm, Làm mịn, và Thể lệ hoá.
Có thể đạt tới CMMI mức 2 trong thời gian rất ngắn như 12 tháng, nhưng rủi ro rơi trở lại mức 1 sau đó cũng rất cao cho nên bạn phải rất thận trọng.
Nhân tiện, bạn có thể cam kết làm cho mọi thứ xảy ra nhưng còn về cán bộ của bạn thì sao? Bạn có thể đạt tới CMMI mức 2 nhưng chi phí cho điều đó có thể còn cao hơn bạn trông đợi. Cách tiếp cận không hợp lí và không hiện thực có thể làm cho nản lòng cán bộ và thất vọng khách hàng. Xin hãy thận trọng khi lập mục đích của bạn.
Hỏi: Chúng tôi cần làm gì để thoả mãn yêu cầu CMMI để có qui trình ước lượng? Chúng tôi làm ước lượng phụ thuộc vào kinh nghiệm cá nhân hơn là dùng dữ liệu lịch sử được làm tài liệu. Điều đó có được không?
Đáp: Để tổ chức đạt tới CMMI mức 2, bạn cần bằng chứng rằng qui trình ước lượng cho việc lập kế hoạch dự án là có và nó được thể lệ hoá (Được xác định, được làm tài liệu, được huấn luyện, được dùng, được đo, được trắc nghiệm và được cải tiến liên tục). Việc thu thập dữ liệu lịch sử và dự định dùng chúng trong ước lượng dự án là đủ tốt. CMMI nói rằng “Dữ liệu lịch sử được dùng mọi nơi sẵn có” điều có nghĩa là sẽ là tốt nếu bạn dùng dữ liệu lịch sử. Tuy nhiên, việc phụ thuộc vào tri thức chuyên gia cá nhân vẫn tốt để đạt tới CMMI mức 2. Tuy nhiên, ở mức 3, có yêu cầu rằng dữ liệu lịch sử phải được dùng cho mọi ước lượng dự án.
Question: Why software projects are still failing at a very high rate?
Answer: There are many reasons for software failure, following are the top five reasons identified by software developers and managers during the survey conducted at CarnegieMellonUniversity:
Software developers do not understanding customers’ needs. They focus mostly in programming and not bother to discuss requirements with customers. They hurry through the planning and design phases to get to programming because that is the skill that they are taught at Computer Science program. This “Code first, plan and ask question later” attitude is the number one reason for project failure. Typically, when finished developers found out that what they built was not what the customer wanted.
Project managers do not have the skill or the training to estimate resources, time, size and scope of the project. Most managers underestimate these factors then cause projects to be late, and cost more. Because most projects are late, many skip the testing phase so their softwares are full of defects which in turn cost more to fix.
Project team members are not well trained in software methods, they do not know how to control changes to the software, losing control of software versions resulting in significant integration and testing issues which in turn create low quality products.
Project Managers decide to switch development tools in the middle of project create confusion among team members then adding more people to “speed things up” to meet schedule requirements which in turn create more confusion and contribute to project failures.
Long working hours creates stressed out developers so they skip few steps such as testing or reviewing to get by which resulting in high defects. Team members start to argue and keep information to themselves which create more personal problems for project.
Question: How can I estimate software size early in a project, since the number of lines of code is not a good choice and difficult to estimate?
Answer: You may want to consider using function points which are a derived metric of program size that can be used in early estimating. Unlike lines of code, function points can be derived from a functional specification or top-level design. In order to come up with consistent estimates, sets of “counting rules” have been formulated by The International Function Point User Group (IFPUG).
Question: Is it possible to estimate the cost of software early in a project? Is it better to wait until late in the project when we know more about the project?
Answer: It is very important to estimate software size, resources, schedules, and costs as early as possible and adjust them accordingly as we know more about the requirements.
Many years ago, software costs comprised a small percentage of overall computing system cost and people ignored it. Today it is the most expensive element in all systems. An error estimating the cost of software can make the difference between profit and loss. Currently, software cost overrun is the most common problem in every software organization because many people still do not pay attention to it or do not know how. Although software cost is very difficult to calculate since it involves many variables—technical, environmental, political, people—it still can be done by decomposition techniques.
Question: Why do software people need training? Aren’t automated tools designed to improve productivity and quality?
Answer: No matter how good your tools are, you still have to rely on people. Staff attitudes and involvement are critical factors in determining overall performance of any software product. Quality software products are brought about by managers who understand their team members’ needs and help them to realize their full potential by effective education, training and awareness. Tools will inevitably follow. Too often organizations have attempted to seek improvements solely through the development of automated tools and then they are surprised when these “solutions” have not worked. A tool is as good as the people who use it—the same applies to methodology. Without proper training, nothing will work well.
Question: Why isn’t software reuse being advocated as part of process improvement?
Answer: Software reuse is one of the best techniques for increasing software quality and productivity. However, the concept of reusable software components and the process of using these components to build systems are not very understood.
Reusable software can be defined as pre-built software components that have been explicitly designed to be used in multiple applications, generally within a given application domain. Reusable components may include requirements specifications, design information, source code, and test cases. The current ad-hoc approach of developing reusable software components, whatever it may be—just built it and people will use it—is not good enough, because such components will likely end up forgotten in a repository.
I believe in order to make reusable software effective, the organization must create a well defined process of using the reusable components. The components must be explicitly designed with reuse in mind, not just anything people can grab and use. The reuse process must be designed for systemic use rather than opportunistic use. That means all reusable components must be thoroughly tested and be used according to the defined process and guideline. The savings on reusable software is not the development time but the time saved on testing and integration.
I always advocate software reuse as a part of process improvement but the capability of an organization to apply this concept is also very important. At CMMI levels 1 and CMMI level 2 organization is too busy with other issues so they can not implement reuse effectively. A solid CMMI level 3 or CMMI level 4 are where reuse can be effective.
Question: Would you recommend the Project Management Institute (PMI) standards?
Answer: The Project Management Institute’s A Guide to the Project Management Body of Knowledge documents many practices of project management. It is well written and considered very good project management standards recognized internationally. However, it is written for all project management disciplines, from civil engineering to manufacturing and it is comprehensive. You need to spend time and training to benefit from using it since some of the most valuable insights into project management have remained buried in the understated style of the document. I have used this standard for many years and found it valuable and I see no problem in using PMI standards since good project management is fundamental to any project. I believe every process improvement member should be familiar with this project management standard.
Question: What is an open system? Why are there so many definitions of an open system?
Answer: There are many different views and definitions of an open system. I believe an open system is a system that implements sufficient open specifications for interfaces, services, and supporting formats. This will enable properly engineered components to be utilized across a wide range of systems with minimum changes.
In order to do this, the system must:
1. Have well defined, widely used, and non-proprietary interfaces/protocols.
2. Use standards developed by industry recognized standard bodies (e.g. IEEE, ISO).
3. Define all aspects of system interfaces to facilitate new or additional system capabilities for a wide range of applications.
4. Explicitly provide for expansion or upgrading through the incorporation of additional performance elements with minimum impact on the system.
Question: As user of software products, I am not happy when I read about software people complaining about their users’ lack of knowledge and inability to make up their minds. I think software people do a bad job understanding my needs, giving me what I want in time and on budget, and providing higher quality. Do they forget who is paying their bill here?
Answer: Customers tend to believe software developers do not understand their needs and software developers always believe customers do not know what they want. Why do we continue to have an “us vs. them” attitude rather than working together as a team to build better systems? How can we continue to define our own positions and fail to communicate with each other? Remember the goal is to build a high quality product.
I believe the ultimate users are the ones who buy the product and they do care about quality, cost, and time to market. They do know that they have a choice in what product they want to buy and what company they want to buy it from.
Question: As a manager, maturity level is very important to me since it is important to my company. We are assessed at CMMI level 1 and have a plan to achieve CMMI level 2 in the next 12 months. I am fully committed to do it right and will do anything. Do you have any advice?
Answer: If a CMMI maturity level is the only goal important to you, then there are several things your organization can do:
1. Improvements would be driven by people doing the work in the organization which means that everybody in your organization must participate in deploying some process improvement tasks.
2. People will be assigned to teams according to their interest and expertise and managers will be assigned as coaches to the teams.
3. New solutions defined by the improvement teams must be reviewed by management and when approved, people must be trained to follow them.
4. Solutions must be implemented in small phases, not all at once, as stated in other blogs: Define, Pilot, Refine, and Institutionalize.
It is possible to reach CMMI level 2 in a very short time such as 12 months, but the risk of fall-back to level 1 after that is also very high so you have to be very careful.
By the way, you may be committed to make things happen but what about your staff? You may achieve a CMMI level 2 but the cost of that may be higher than you expect. An unreasonable and unrealistic approach may result in staff attrition and customer frustration. Please be careful when setting your goal.
Question: What do we need to satisfy the CMMI requirement to have an estimating process? We do estimate depend on personal experience rather than use of documented historical data. Is it OK?
Answer: For an organization to achieve a CMMI level 2, you need evidence that an estimating process for project planning exists and is institutionalized (Defined, Documented, Trained, Used, Measured, Verified, and Continuously Improved). The collection of historical data and the intention of using them in project estimates are good enough. The CMMI states that “Historical data are used where available” which means it would be nice if you use historical data. However, depending on personal expertise is still OK for achieving CMMI level 2. However, at level 3, there is a requirement that historical data be used for all project estimating.
