Building the Data Warehouse

Скачать в pdf «Building the Data Warehouse»

■■ Methodologies usually show activities as occurring once and only once. Indeed, while some activities need to be done (successfully) only once, others are done repeatedly for different cases (which is a different case than reiteration for refinement).

■■ Methodologies usually describe a prescribed set of activities to be done. Often, some of the activities don’t need to be done at all, other activities need to be done that are not shown as part of the methodology, and so forth.

■■ Methodologies often tell how to do something, not what needs to be done. In describing how to do something, the effectiveness of the methodology becomes mired in detail and in special cases.

■■ Methodologies often do not distinguish between the sizes of the systems being developed under the methodology. Some systems are so small that a rigorous methodology makes no sense. Some systems are just the right size for a methodology. Other systems are so large that their sheer size and complexity will overwhelm the methodology.

■■ Methodologies often mix project management concerns with design/devel-opment activities to be done. Usually, project management activities should be kept separate from methodological concerns.

■■ Methodologies often do not make the distinction between operational and DSS processing. The system development life cycles for operational and DSS processing are diametrically opposed in many ways. A methodology must distinguish between operational and DSS processing and development in order to be successful.

■■ Methodologies often do not include checkpoints and stopping places in the case of failure. “What is the next step if the previous step has not been done properly?” is usually not a standard part of a methodology.

Скачать в pdf «Building the Data Warehouse»