Relationship to the Software Lifecycles
There is no rule which says all parts of the client-server application must be created under the same software lifecycle method. Choosing the same lifecycle method for all parts has the advantage of allowing a common set of documentation standards, tools and programmers to be shared among the parts. On the other hand, the software running on the user's device may not lend itself to the same lifecycle methods as the central systems.
For example, the software running on a central system in a client-server architecture must be absolutely reliable. Many users depend on its proper operation. If it fails, many users will be unable to work. In many systems, the central system software is not usable until it is complete - it cannot be delivered in small pieces. Actually many server side applications are still using waterfall as their lifecycle design.
The software running on the user's device is much less critical to the entire system. Since this software must present displays of data to the user, it is much more subjective than the central system software.
The prototyping model would probably not work well with the client/server architecture. The architecture requires thorough implementation to reduce possibility for error. The prototyping model calls for a rapid prototype to be developed, with not much time for thorough implementation, so this life cycle wouldn't be a very good choice to use along with the client/server architecture. Client-server architecture, because of its very nature, can be a fragile thing if not tested and implemented properly. Response speed and reliability are especially important in this type of architecture, so breezing through its implementation would not be recommended.
The prototyping model is also better for small-scale systems, which are rarely introduced, when a client-server architecture is involved.