17.3
If there is disability in customer involvement in the development process, adopting the Agile methods is questionable. The requirement for the development members to be interacting with the other much closely can be uncomfortable to many. The prioritizing changes can be very complicated if there are even a few number of clients. While it’s focused on the interactions and rapidity, simplifying the work result is difficult not to interfere with the schedule of development.
17.3
ADVANTAGES: Being very short, they represent small chunks of business value that can be implemented in a period of days to weeks. It allowes developer and client to discuss requirements throughout the project lifetime. Needs very little maintenance. Only being considered at the time of use. Maintaining a close customer contact. Allows projects to be broken into small increments. Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process. May be easier to estimate development effort.
DISADVANTAGES: Without accompanying acceptance tests, they are open to interpretation which makes them difficult to use as the basis for agreement, They require close customer contact throughout the project which in some cases may be difficult or may be unnecessary overhead, Can have difficulty scaling to large projects. Rely more on competent developers, User stories are regarded as conversation starters. Unfortunately they may not capture where the conversation ended and fail to serve as a form of reliable documentation of the system.
17.5
Writing tests first implicitly defines both an interface and a specification of behavior for the functionality being developed. Problems of requirements and interface misunderstandings are reduced. The tests can catch the problems that the new code has introduced. It avoids the tendency to skip the test so that the schedule can be maintained.
However, programmers prefer programming to testing and sometimes write incomplete tests that do not check for exceptional situations. Furthermore, some test can be very difficult to write. And it is difficult to judge the completeness of a set of tests. Relying on the customer to support acceptance test development is sometimes a major diffculty in the XP testing process.
17.6
Because the bugs are caught early during the programming by reviewing from each other, learning and motivating for each other to become better programmer, easily overcoming diffcult problems together, and since the knowledges are shared between more than one person, unexpected departure of one programmer can’t affect the devepment process
17.8
a. Develop a throw-away prototype, evaluate, it then review the system requirements. Develop the final system using C.
The speed of development will be very quick, and possibly the steps toward the solution can be minimized. If the prototypes were developed using the final code specification, C, then the process itself can be smoothly migrated to the final system development. However, this prototyping required close involvement of customers, which is not easy and if the critical requirement emerges during the prototyping, it may have to go back to the beginning.
b. Develop the system from the existing requirements using Java, then modify it to adapt to any changed user requirements.
This will deliver the running application at the beginning, allowing customers to find the advantages and disadvantages as early as possible. But if the new requirements emerge, it can’t avoid to be implemented and since it’s developed using Java, it is limited to use Java, or it has to be developed all over again.
c. Develop the system using incremental development with a user involved in the development team.
Being open to the changes at every step, it’s very flexible approach to solve the problem. And still maintain its functionality to be usable by the customers. However, it requires close involvement, feedback from the customers who may have difficulties in evaluating the product objectively.
17.9
The development must consider the important aspects of critical management for the money and how it’s spent. The clarity and security is the essential part of the system. Thus, it must be able to prove its clear and legible representation of data flow, in this case the source and destination and amount of the money, and the means to protect the system from any kind of attack, intentional or unintentional ones. The involvement of customers must start from the paid workers and be expanded to the volunteers for their privileges differences and to minimize the complexity caused by too many customers. The phases of the prototyping must be parted into at least two phases, one for building the secure structure and the other for user interface building. Once the secure structure is finished, the user interface builiding can be simplified by numerous tests and implementing users requirement developed from prototype testing.
29.1
There are constant changes of requirements, descriptions of the project. The document within the project may not have long-term relevance and are not needed for future maintenance of the system. In a way, the specific name of the document is not absolute. And it may be meaningless to the readers who cannot perceive the it’s placement in the project. However, it’s possible for the project to have minimal changes within the relationship of the documents. The relationship or the hierarchy of the documents can be used to name the elements uniquely, without the hassle of changing the title when the need arises. It’s like referring to the varibles in the programming without needing to know the values of them.
29.6
Whenever building the system from the components, there are several questions need to be answered. Have all the components that make up a system been included? Has the appropriate version of each required component been included? Are all data files available? If there is no confusion among the name for referencing? Is the appropriate version of the compiler and other required tools available? And the dependencies between components must be specified clearly. For building a system on a host computer for some target machine, it must have the assurance that there are no discrepancies, differences which cannot be resolved. The effort for compiling the components will be meaningless if it cannot be deployed to the target machine and working properly.
29.7
Because they maintain the original version of the software, or the system which the subsequent derivatives were generated from. Being used as the part of the tracking the version, for instance, to restore certain feature lost during the development, even if they are obsolete, it’s much safe to maintain the system. Specific language, or the associated interpreter may not be supported anymore to be installed to the new system, so it’s better to keep the whole system which include these important tools.
