Chapter 5
Since Brooks discussed the fact that the rational model is not ideal. He proposes that maybe a designer might ask if there is a model that exist that does not have the problems that the rational model has ,but also has the same core values as the rational model. Brooks begins discussing a couple of different model types that may be considered a solution to the questions the designer has. The first model Brooks discusses is the evolution model. This model is basically our "prototype the design then fix the design" model that we have discussed in class. A model similar to the evolution model is Raymond's Bazaar Model. Brooks compares this model the the open source world of Linux. Brooks explains that this idea works because the users are also the builders of the products they wish to be using. The last model that Fredrick Brooks discusses in this chapter is Boehm's spiral model. Brooks describes this model as the most promising of all of the other alternatives, but he does believe it needs some more tinkering.
Chapter 4
Sometimes effective design can be hampered by situations governed completely by bureaucracy. Those involved may have little understanding of design and expect absurd things to be possible. Not only this, they may be unwilling to allow for a more logical solution that is outside of the design scope itself. The many people involved can bring their own set of requirements and parameters that the project must meet and not be able to reconcile these needs with each other. This necessitates that the designer analyze all of the requirements and try to decide which are feasible and appropriate for the project. Projects should undergo a better process than this during initial creation of the scope that takes into account the relative importance of various requirements. Setting all of these requirements at the beginning hinders appropriate design as well since little knowledge about the cost and difficulty of achieving those requirements is so difficult to measure at the very beginning. Experienced, knowledgeable people should be involved/in charge from the outset to help field all of these requirements.
In theory, people should be able to follow a logical plan: client trusts designer and builder and pays appropriately for their expertise, the designer focuses foremost on the client's needs, and the builder attempts to build the best object possible for the cost and timetable. The problem with this is that each of these 'players' almost invariably will attempt to obtain some gain over the others, often through deceit. This necessitates that contracts be introduced to keep the design process flowing as it should and help prevent each party from attempting to cheat the others. However, trust is still required in the contracting process to let design run smoothly. This usually involves the client paying based on time or percentage to the designer, and the designer coming up with an accurate set of plans so for the builder to analyze and use in pricing and bidding. This process will probably need to be loosened up to allow for appropriate flow for each party, meaning each party will have to do small pieces at a time for proper communication to occur.
No comments:
Post a Comment