Millions of lines of code have been developed to support scientific research. The code is hard to understand and maintain, lacking documentation and version control, and is continually “re-invented” as the software developer’s move on to new projects.
Why software fails in scientific research and how to fix it’ will investigate how this situation has come about, why it is important to the future of research, and what can be done about it.
Management asked all the project mates to avoid the six most common causes of project failure:
Unrealistic Scheduling for the completion –
Most of the peoples think that pushing the S/w Developers for an aggressive deadline for the project would accelerate the work, but it actually delays. When an unrealistic deadlines given to the team then they start racing through the S/w requirements, produce a design in a hurry and directly rush to the coding. These will results into the poor-quality of work with the wrong functionality of the product.
Insufficient Staffing -
To complete the project in a given time with nice quality of work and efficiently, solution is to assign an adequate number of people. This helps in the effective team work which is required for the project.
Changing Requirements during Development of the Project –
To start the implementation of the project, engineers must know what product is to be build. Unfortunately, management, marketing and even customers often don't know what they want. They provide the incomplete or sometimes incorrect requirements, while the requirements normally change in the early phases of a job but when the team starts working on that then later on they realizes some more functionality to be added in it and some changes too. This will simply waste time and money and disrupt the work.
Poor-Quality of Work –
To meet an accelerated delivery date set by boss, management pushed their engineers, and they just rushed through the design and coding and skipped all of the quality reviews and inspections. This will result in many defects while testing, but management argued for delivering the software and fixing defects later. Management met the deadline, but the system was a disaster. It was so unreliable that the software had to be fixed every time a change was made in the project. When executives push for unrealistic schedules, the project either will be late delivered or will produce a product that doesn't work. There's a saying about software quality: "If it doesn't have to work, we can build it really fast."
Insufficient number of resources could also result in the failure of the software.
To save the development time and money COTS is the best way to approach. COST is Commercial off-the-shelf Software. But the only condition with it is to use it properly otherwise it can be result in a disaster. This is generally used in production as a trouble-shooting.
