Software problems in general defy definitive descriptions. The abstracted version of a software problem that designers start with may at some later stage in the development process be found to be structurally deficient— sometimes in some fundamental way that may render the rest of the development problematic. Abstracting away the complexity of the problem in an attempt to get at the problem's essence may thus carry with it risks and uncertainties that could eventually spell disaster for the project.Software projects invariably address problems that are conceptual in nature. Unlike engineering or architectural problems, where tangible products are the expected end of the development, software "solutions" are abstractions of symbols and words, put together under specific guidelines and methodologies to satisfy some functional requirements that constitute the software problem. There are, at the core, real and fundamental differences between the development of software as an abstract or conceptual artifact and other physical artifacts such as buildings or bridges. Fred Brooks's (1987, 12) description of software as "pure thought-stuff, infinitely malleable" and as "invisible and unvisualizable" underscores the difficulty of problem formulation in software development. Although the software may be "invisible and unvisualizable" inasmuch as the human eyes are concerned, the behavior of the software must be visualizable in the mind's eye of its creator or designer. Part of the problem-formulation difficulty arises from the designer's inability to fully conceive of all the possible behavioral states of the working software prior to its implementation (Parnas 1985).In discussing the dilemmas that planners face in tackling real-world problems with several stakeholders, Rittel and Webber (1973) have coined the term wicked problems to convey not only the difficulties but to some extent the sense of frustration planners experience in dealing with planning problems in a pluralistic society. The term wicked problems is defined not from a moralistic or ethical perspective but rather from the standpoint that these problems are representative of an amorphous class of complex problems that defy comprehensive descriptions. Such problems are usually characterized as one of a kind. Software problems (at least of the type discussed here) belong to this class of problems. Like planning problems, software projects tend to deal substantially with problems that are unique.Every software project is bound to have peculiarities that override any apparent commonalities that the project may appear to have with previously implemented systems in the organization. It must be recognized that every new software project is intended to satisfy an identified need in the organization's systems portfolio. Also, like Rittel and Webber's planning problems, software projects handle problems that have no set stopping rule or criteria for arriving at the desired "solutions" or implementation. Consequently, the entire design effort is geared to coming up with a satisfactory implementation of a software problem that does not have a "right or wrong solution." The implementation can rather be characterized as good or bad in terms of whether it addresses the functional requirements of the systems problem. The implementation arrived at has broad consequences for the organization and, wickedly, offers practically little chance to learn by trial and error. So the systems developers may not be able to come up with alternative satisfactory implementations due to the enormous costs of time and money involved in the process.Fundamentally, software projects tend not to have a definitive formulation of the information requirements at the core of the development effort. Any number of groups of stakeholders, in particular the users, may have their own perspective on the nature and significance of the problem and what the software must be able to accomplish. The need for consensus among the stakeholder groups becomes crucial to bridging the gap among the differing interpretations of the information needs of the organization. Arriving at a satisfactory formulation of the software problem is not a trivial task and may often be the hidden source of problems uncovered at later stages of the development process. In addition, there is a need to prioritize the requirements problems and introduce some element of flexibility into the development process. This will allow for later incorporation of some deferred requirements problems into an implemented system. It will also help to control for the complexity and size of the project in the initial stages of development.The tools and procedures of software development vary as widely as the problems the projects tackle. There is something unsettling about the variety of approaches to software projects. The intrinsic conceptual nature of the problems the projects are intended to address is probably partly to blame for this disturbing state of affairs. As noted earlier, software projects are often abstracted from real-world problems, which are difficult to model conceptually without losing some inherent attributes of the problems in question. In the final analysis, software developers are left with no option but to come up with a variety of attempts to get at the essence of the problem, to counter the fundamental difficulty of dealing with the "invisible and unvisualizable" characteristics of the projects. In addition, the learning that takes place on a project is for the most part not transferable wholesale to new projects. Each new software project carries within its structure some intrinsic properties that make it unique and thus not easily amenable, adaptable, or applicable to information transfer from other successfully completed and implemented projects.The problem-solving processes of software development projects are in general not repeatable, nor do they have parts that can be grafted onto new projects without major reworking or modifications. The software developer is thus forced into a selective trial-and-error approach to building software as each new project takes on a new software problem. The experience gained from earlier projects may help inform us about some feasible options, but nothing in the form of concrete "solutions" can be assumed as applicable to new software development problems in the organization. The selective trial-and-error approach does contribute to the proliferation of tools and procedures, as each new software development problem forces the developers to come up with novel and often untried and untested means of accomplishing the desired functional requirements. The tools and procedures that aid in the successful implementation of the software problem then become part of the collection of promising toolkits to be consulted as appropriate in future software development projects.
لطفا منتظر باشید ...
