Fixed price software development is a complex subject. Because software development is a complex subject. A general conception of the market for software applications has interest in fixed price development, but the history of fixed price contracting is littered with exemplary failures.
Fixed price contracting refers to a contract for a single project cost, in contrast to forms of flexible development contracts that permit cycles of evolution in the development of the project. Flexible or cyclic development contracts are necessary to monolithic projects that encompass broad scope, and projects that involve an element of novelty (not well known). The contractor's ability to predict the future of a development project is inversely proportional to the complexity and novelty of the deliverable product.
The region for success with fixed pricing is in products that are unambitiously sized to, and well known to the contractor. In this case, the development work to be done requires only a few build, test, release cycles in the scope of project -- and these cycles may be opaque to the terms of the agreement. This is a small region in the world of software development, but it exists.
In the abstract, success in fixed pricing depends on technical project management, first contractor selection and second the definition of work. A "successful failure" is a delivered software product that performs poorly, is hard to maintain, is awkward in use, or is inflexible. It is this scenario of the overt success but practical failure that is the principal opposition to fixed price contracts. With evolutionary development cycles, issues in performance and usability can be ironed out subsequent to an initial delivery.
There is always an argument in favor of fixed pricing. It should be possible to arrive at a market place wherein contractor technical capabilities are better known than not. And it should be possible to manage large projects as a set of smaller ones, sized for their most practical development. The allure of this possibility has resonance, because software projects are best organized as a composition of parts, and the ultimate product qualities of usability and flexibility are proportional to the technical independence of a product's component parts.
Unfortunately the subject of software project management is a messy one, principally described for its difficulties, and the tactics and strategies for dealing with and managing these problems. A problem with a solution is no longer a risk to success. The solution is to employ an evolutionary development process, as there's always an element of the unknown, including the necessity for competitive business evolution.
If project management were cyclic, development units could be fixed. This would work if the contractor could be rehired in a predictable and suitable way, and this contracting scheme becomes an open subject for a solution. Perhaps the contract is an open cycle of fixed units.
Generally, however, practical contracting will tend toward the cyclic. Each role, manager and developer, has limits to its capacity, and effective repeatable annual results depend on a practical work flow.