Nghiên cứu này thấy nhiều lí do cho thất bại phần mềm, sau đây là năm lí do hàng đầu mà nghiên cứu này nhận diện ra:
Đa số người phát triển phần mềm không tính tới thời gian hiểu nhu cầu khách hàng. Họ không được đào tạo để trắc nghiệm các yêu cầu với khách hàng mà vội vàng qua ngay pha lập kế hoạch và thiết kế để sang viết mã. Thái độ “Mã trước, và hỏi câu hỏi sau” là nguyên nhân số một cho nhiều thất bại dự án. Cuối cùng, khi phần mềm được đưa ra, người phát triển mới thấy ra là điều họ làm không phải là điều khách hàng muốn và họ phải sửa lại nó và điều đó tốn nhiều thời gian và tiền bạc.
Đa số những người quản lí dự án không có kĩ năng để ước lượng tài nguyên, thời gian, kích cỡ và phạm vi dự án. Phần lớn những người quản lí hoặc ước lượng thấp nỗ lực hoặc ước lượng tất nhưng lại đặt kế hoạch theo lịch biểu được khách hàng trao cho họ. Họ quản lí dự án theo lịch biểu không hiện thực và làm cho dự án bị chậm. Bởi vì sức ép lịch biểu, nhiều người quản lí yêu cầu người phát triển bỏ qua kiểm thử để đáp ứng lịch cho nên sản phẩm phần mềm cuối cùng đầy lỗi, điều này làm cho công ti tốn kém nhiều tiền bạc và thời gian hơn để sửa chữa.
Đa số các thành viên tổ dự án không được đào tạo trong qui trình hay phương pháp phần mềm, họ không biết cách kiểm soát thay đổi với phần mềm, mất kiểm soát phiên bản phần mềm tạo ra các vấn đề lớn về tích hợp và kiểm thử, điều đến lượt lại tạo ra sản phẩm chất lượng thấp và chi phí nhiều hơn để sửa chữa.
Khi dự án bị trục trặc, người quản lí quyết định thêm người để “tăng tốc mọi sự” để đáp ứng thời gian theo lịch biểu. Điều này tạo ra thêm vấn đề, lẫn lộn, và gây ra sản phẩm chất lượng kém, điều gây chậm trễ và cuối cùng tốn kém nhiều hơn.
Nhiều giờ làm việc lâu tạo ra căng thẳng lớn cho thành viên tổ phần mềm. Nhiều người trong số họ bỏ qua vài bước trong qui trình phát triển như kiểm thử, kiểm điểm để đáp ứng lịch biểu, điều gây ra sản phẩm lỗi cao. Trong tình huống bị căng thẳng, các thành viên tổ sẽ tranh cãi lẫn nhau, oán trách nhau, và thế rồi giữ thông tin cho riêng mình thay vì chia sẻ. Thiếu thông tin tạo ra lẫn lộn, dư thừa, lỗi, điều lại gây ra nhiều vấn đề cá nhân cho dự án phần mềm. Bởi vì thất vọng, nhiều người rời bỏ công ti làm cho việc đổi người cao, điều là bổ sung thêm vấn đề cho dự án phần mềm.
Nghiên cứu này kết luận rằng tất cả các vấn đề trên đều được gây ra bởi việc đào tạo phần mềm kém ở nhà trường. Sau khi kiểm điểm lại giáo trình của nhiều đại học, tổ nghiên cứu lưu ý rằng đa số sinh viên không được dạy về kỉ luật kĩ nghệ phần mềm bản chất như kĩ nghệ yêu cầu, quản lí dự án, lập kế hoạch dự án, phương pháp và qui trình phần mềm, và làm việc theo tổ. Đào tạo hàn lâm hiện thời tập trung phần lớn vào ngôn ngữ lập trình, điều chỉ là một phần nhỏ của qui trình phát triển phần mềm.
Trong nhiều năm, công nghiệp phần mềm đã phàn nàn về thiếu đào tạo môn này trong đại học nhưng vấn đề vẫn còn chưa được giải quyết. Sự kiện là đào tạo các môn kĩ nghệ phần mềm yêu cầu kinh nghiệm công nghiệp nào đó mà nhiều giáo sư hàn lâm không có cho nên họ bỏ qua nó. Sự kiện khác là lĩnh vực phần mềm đã thay đổi nhanh thế và thật khó cho các giáo sư theo kịp với những thay đổi này. Nhiều đại học không muốn mạo hiểm danh tiếng của mình bằng việc chấp thuận cái gì đó mới mà họ không cảm thấy thoải mái.
Để đổi từ khoa học máy tính sang kĩ nghệ phần mềm yêu cầu thay đổi sâu sắc về lập kế hoạch phương pháp dạy và các bài học, điều đại học không thể đảm đương được. Như với bất kì thay đổi nào, dù xứng đáng đến đâu, bao giờ cũng bị chống lại.
Ngày nay, phần lớn các dự án phần mềm đều lớn và phức tạp. Sản phẩm phần mềm hiếm khi có thể được phát triển bằng tổ vài người. Các phương pháp hiện thời yêu cầu tổ phát triển được tổ chức theo cách sử dụng hiệu quả kĩ năng của mọi người. Có một số vai trò, trách nhiệm cho các thành viên tổ và họ phải được tổ chức tương ứng với tri thức, kĩ năng và kinh nghiêm như người quản lí dự án, người phân tích nghiệp vụ, chuyên viên mạng, người kiểm thử, người phát triển, đảm bảo chất lượng, chuyên gia cấu hình v.v.
Trong dự án lớn, trao đổi là mấu chốt cho nên khách hàng, người dùng, thành viên tổ phải làm việc cùng nhau và trao đổi với nhau trên cơ sở thường xuyên. Tuy nhiên làm việc tổ lại không được dạy trong các chương trình hàn lâm truyền thống và trong các trường hàn lâm truyền thống, bất kì cộng tác nào giữa các sinh viên đều bị coi là “gian lận” cho nên nhiều sinh viên vẫn gặp khó khăn trong làm việc cùng nhau.
Toàn cầu hoá bắt đầu làm thay đổi điều đó, khi các công ti có thể thuê người từ bất kì đâu và không nhất thiết phải thuê người trong biên giới nước họ. Với sự thiếu hụt người làm phần mềm trong ngành công nghiệp đang bành trướng nhanh này, nhiều công ti toàn cầu bắt đầu thuê người làm phần mềm và đưa họ vào công việc ở nước họ hay mở các tiện nghi ở nước cung cấp dư thừa về công nhân phần mềm. Mỗi năm, Mĩ phải đưa vào trên 80,000 công nhân phần mềm, phần lớn từ Ấn Độ qua chương trình thị thực đặc biệt H1B. Nhiều nước châu Âu đang làm cùng điều đó với các công nhân có đủ tư cách từ Nga, và Đông Âu. Tuy nhiên, vấn đề nền tảng vẫn còn là liệu những người làm phần mềm này có tri thức và kĩ năng đúng không?
Cuộc khủng hoảng tài chính bắt đầu làm thay đổi rằng, khi công ti chậm thuê người do ngân sách bị hạn chế, họ có nhiều thời gian để lựa người có kĩ năng đúng và đào tạo đúng. Thay vì thuê người có bằng cấp ở đại học, nhiều công ti đang áp dụng kĩ thuật phỏng vấn theo kịch bản để nhận diện công nhân có tri thức và kĩ năng đúng. Thay vì đi sang bất kì nước nào, họ nhận diện các nước có chương trình đào tạo tốt, đặc biệt chương trình đào tạo đang hiện hành cùng nhu cầu của họ. Theo nhiều người quản lí phần mềm, cuộc khủng hoảng tài chính này là việc chạy không ổn trong thời hạn ngắn nhưng việc lấy nhân viên là đầu tư dài hạn cho nên các công ti phải lập kế hoạch cho tương lai bằng việc nhận diện công nhân tri thức, người có khả năng tạo ra nhiều cơ hội hơn, nhiều sản phẩm tốt hơn cho doanh nghiệp của họ.
According to the latest study of the U.S Software industry, many software projects are still failing at very high rate despite so many improvement attempts. The study found many reasons for software failure, following are the top five reasons identified by the study:
A majority of software developers do not take time to understand customers’ needs. They are not trained to verify requirements with customers but hurry through the planning and design phases to get to coding. This “Code first, ask question later” attitude is the number one reason for many project failure. Eventually, when software is released, developers found out that what they built was not what the customer wanted and they have to fix it and it costs a lot of time and money.
A majority of project managers do not have the skill to estimate resources, time, size and scope of the project. Most managers either underestimate the efforts or do not estimate at all but based their plans on the schedule given to them by customers. They manage projects according to an unrealistic schedule and cause projects to be late. Because of schedule pressure, many managers asked developers to skip testing to meet the schedule so the final software product is full of defects which in turn cost the company more money and time to fix.
A majority of project team members are not trained in software process or 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 and cost much more to fix.
When project is in trouble, managers decide to add more people to “speed things up” to meet schedule dateline. This creates more problems, confusions, and result in poor quality products that are late and eventually cost more.
Long working hours creates significant stress for software team members. Many of them skip few steps in the development process such as testing, reviewing to meet the schedule which resulting in high defects product. In stressful situation, team members will argue with each others, blame each others, and then keep the information to themselves rather than sharing. Lack of information creates confusions, redundancies, defects which create more personal problems for software projects. Because of frustration, many leave the company and cause high turnover, which add more problems to the software project.
The study concluded that all of the above problems are caused by poor software trainings in schools. After reviewing several university curricula, the research team noted that a majority of students are not taught essential software engineering disciplines such as requirements engineering, project management, project planning, software methods and process, and team work. Current academic trainings are focusing mostly on programming languages which is only a small part of the software development process. For many years, the software industry has complained about the lack of discipline training in universities but the issue still remains unsolved. The fact is software engineering disciplines training requires certain industry experiences that many academic professors do not have so they ignore it. Another fact is the software field has changed so fast and it is difficult for professors to keep up with changes. Many universities do not want to risk their reputation by adopting something new that they do not feel comfortable. To change from computer science to software engineering requires profound changes to the teaching method and lessons planning which university can not afford. As with any change, no matter how worthwhile, it always be met by resitance.
Today, most software projects are large and complex. Software product can rarely be developed by a few persons team. Current methods require development team to be organized in a manner that results in efficient use of people’s skills. There are certain roles, responsibilities for team members and they must be organized according to knowledge, skills and experiences such as project manager, business analyst, requirements specialist, technical leaders, chief architect, platform specialist, network specialist, testers, developers, quality assurance, configuration specialist etc. In large project, communication is crucial so customers, users, managers, team members must work together and communicate with each others on a frequent basis. However teamwork is not taught in traditional academic programs and in traditional academic school, any collaboration among students is considered “Cheating” so many students are still having difficulty in working together.
Globalization begins to change that, as companies can hire people from anywhere and not necessary have to hire them within their borders. With the shortage of software people in a fast expanding industry, many global companies begin to hire software people and bring them to work in their country or opens facilities in country that provide abundant software workers. Each year, the U.S have to bring in over 80,000 software workers, mostly from India via special H1B program. Many European countries are doing the same with qualified workers from Russia, and Eastern Europe. However, the fundamental question is still remain on whether these software people have the proper knowledge and skills?
The financial crisis begins to change that, as companies are slow to hire due to restricted budget, they have more time to select people with the right skills and right training. Instead of hiring people with degrees from university, many are applying scenario interview techniques to identify workers with the proper knowledge and skills. Instead of go to any country, they are identify countries with good training programs, especially training programs that are current with their needs. According to several software managers, the financial crisis is a short term glitch but staffing is a long term investment so companies still have to plan for the future by identify knowledge workers who can create more opportunities, better products for their businesses.
