21.4) Ex 21.4 Explain why an object-oriented approach to software development may not be suitable for real-time systems.
In general, object-oriented approaches and languages are used for general problem solving. They abstract the underlying construct that they run on in exchange for a more human-like language and approach to more easily conceptualize a problem and its solution. The best example is a comparison between Java and C and their concepts of reference vs pointer. Java being an object oriented language uses the concept of a reference to abstract a pointer. While in C there exists no abstraction, a pointer is simply a number representing the actual location in memory of a piece of data. The key here is that while both fundamentaly use the concept of something representing a piece of data in memory, Java implements references to limit capabilities of the programmer while C allows direct manipulation of the system through pointers. References are limited in how they can be manipulated as a consequence of being object-oriented. Because of this orientation towards abstraction it does not allow for the tight control and manipulation of a computer system, which is critical for development of real-time systems.
22.6) Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise.
Fixed-price contracts can very easily create scenarios that result in a flawed products. While they might be enticing to a client because of the fixed price, these types of contracts are highly unforgiving to the contractor. Any unexpected issue or change in requirements is a net loss for the contractor with no course for compensation. Coupling this pressure with a lack of intense oversight over the contractor creates a strong incentive for the contractor to cut costs in any way that is possible. Corners would cut because the contractor would have to value their own company over the product that they are creating for the client. But even this has a bad outcome, because if the product developed is subpar because of these issues mentioned previously, it would effect the contractor's reputation. In a perfect world, the fixed-price model would be superior, but the unexpected and turbulent nature of software engineering in far too unpredictable for these types of contracts to be feasible in the long term for both the contractor and the client.