Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


3.1. DESIGN PROCESS

According to Asimow (in Coyne et al., 1990), a generic design process has three steps:

  1. Analysis
  2. Synthesis
  3. Evaluation

The analysis step assesses customer needs and determines the requirements and constraints. The synthesis step builds, configures, assembles, and integrates components that should satisfy or optimize the requirements and constraints. The evaluation step verifies and validates the design artifact. This process may be repeated many times as complex design problems are decomposed in greater detail, with the evaluation leading to a new understanding and revised analysis of the problem.

Design for ill- or semi-structured problems is usually best accomplished as a process of iterative deepening, recursively applying Asimow's design process. Later in this section the author will propose a more comprehensive design model. In the IS domain, for example, two Systems Development Life Cycle (SDLC) methodologies are dominant. Barry Boehm's Spiral Model is now favored for ill- and semi-structured problems, such as ES development. In this approach, designs are selected from the most closely matching prototypes, and then are iteratively refined. Unlike the linear Waterfall Model, the Spiral Model allows for more customer participation throughout the design, development, testing, and implementation processes. In addition, there is fast and frequent feedback to earlier phases of development. Also, prototypes are used to quickly create a design artifact to which the client can respond.

3.2. REQUIREMENTS

Reengineering provides powerful techniques to transform needs into requirements. Differing groups, including customers, users, domain experts, designers, and owners, may have convergent or competing interests. These varying interests are expressed in terms of needs, preferences, and expectations. Requirements and constraints are then articulated from needs, preferences, and expectations that have been filtered through values and perceptions. Requirements are often expressed in terms of functionality, quality, service, and adaptability. Constraints are often expressed in terms of available resources and external limitations. Next, the resulting specifications are then assessed, prioritized, and negotiated across interest groups based on importance, need, resources, and constraints.

3.3. CONSTRAINTS

Constraints are limitations imposed on the design description. Resource availability is the most common constraint in developing and implementing designs. This includes financial, raw material, intellectual, computing, and human resources. Other limitations may include physical, temporal, logical, technical, social, political, legal, regulatory, and cultural constraints.

Design limitations can be viewed as either hard or soft constraints (Ruby and Kibler, 1993). Hard constraints are Boolean-valued parameters that satisfy important design goals. Soft constraints are real-valued variables that measure the quality of a solution. Hard constraints must be met, while soft constraints are optimized.

Kolodner (1993) has pointed out that design problems can be over-constrained, as well as under-constrained. JULIA is a case-based reasoner (CBR) program that designs (plans) meals for parties. In a well-known case, some guests have preferences and many guests have constraints -- types of food they will not eat. JULIA recalls prior meals or dishes from its case base that most closely match the preferences and constraints of its guests. It then adapts the best partial meal designs and creates dishes that will satisfy all the guests.

3.4. DESIGN REALIZATION AND OPTIMIZATION

Once conceptual design specifications have been defined, designers begin the process of optimizing and negotiating between design requirements and those design constraints that limit the realization of the ideal or optimal design. Some requirements are desireable, but not essential, and can be reduced or eliminated; some constraints are artificial or cultural, and can be altered or minimized. If requirements are highly valued, resource constraints can sometimes be lifted. However, resource estimates are only meaningful once a conceptual design has been developed into a prototype and tested. Requirements, by themselves, often give little guidance on how to generate designs (Kolodner, 1993). Often, resource constraints can be overcome by lengthening the project development time frame, or breaking the project into smaller releases.

When problems are ill-structured and therefore under-constrained, a very large number of solutions may be possible, and often must be assessed in order to find the best one. For example, "Architect, design me a house; make a statement; cost is not a problem." In this case, the only limits are those set by the architect and the local building and zoning codes. Creative thinking that begins with the conceptual requirements and constraints as an anchor may be quite useful in exploring and defining the design problem, as well as generating ideas to reach design solutions. Texts by Couger (1996) and Van Grundy (1992) provide excellent advice on available techniques and when to apply them.

However, when design problems are over-constrained, often no solution is possible. Either the problem definition of the design artifact must be altered, or some of the constraints must be removed. For example, "Fifty thousand dollars is the most I can afford to spend on this house." Either the definition of a house must be loosened or broadened to be a "shelter" or at least one constraint must be lifted. Redefinition would mean that a house trailer, recreational vehicle, mobile housing, or owner-built housing might be solutions. Another solution would be to allocate more funds to the house-building budget. A third alternative might be to develop the dream house in stages over several years. Of course, in the case of designing a house, there might be more than 50 significant variables, and as many constraints.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.