HW18: Chapter 21 and Chapter 22

21.4 Explain why an object-oriented approach to software development may not be suitable for real-time systems.

The reason that an object-oriented approach to software development may not be suitable for real-time systems is heavily tied to the architecture of real-time systems. It can be difficult to achieve concurrency with object-oriented programming (OOP) due to performance overhead. The features of OOP lend to this. Take polymorphism for example. Including multiple versions of the same method for different objects can add significant overhead. Further, the structure of an OOP system contains may objects which complete many small tasks which only add to overhead.

Overall, real-time systems are naturally timing-critical, so they require that concurrency (and efficiency) OOP lacks. The nature of OOP contributes to power consumption and leaves us with a lack of control over real-time systems. A real-time system requires a more process-oriented approach like those described in the book (observe and react, environmental control, process pipeline) to support concurrent processes.

Here is a helpful blog I read about this topic.

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.

Moving project liability to the contractor will naturally make the client less accountable for holding up their end of the bargain. One major facet of this is proper communication: clear delivery of information about what they desire. Consider when the project timeline gets dragged out because the customer wasn’t clear about the desired interface or expectations for a feature. Of course, these changes are so complex when we’re talking about an entire software system. Adding or removing something at the last minute could bring in countless new issues (bugs) that add not only time but also risk of failure to the project.

When the client knows they paid a fixed price for the contractor, there’s a much higher risk that they will cause and/or jump on these kinds of issues. They’re not worried about racking up fees for an extended project timeline. This could make them, again, much less careful in communication. It’s unfair to the contractor who should only be held accountable for project issues they cause. Hence, in my opinion, the customer is the one who should carry the project risk so that he/she is on the same page as the customer about keeping on top of project deadlines.

• 2021 11
• 2020 22