find and solve ||
Please wait.....

Characteristics of Software Development Strategies

The software development process models described in this chapter share several characteristics. These include an emphasis on the role of requirements engineering; the use of a multistage decomposition approach derived from the Waterfall Model; documentation requirements; stakeholder involvement; project management; objectives related to economic or business constraints; and the implicit or explicit adoption or embedding of recognized best practices. Each of these characteristics will be considered.

All the models, aside from the primitive code-and-fix approach are problem-solving approaches that apply requirements engineering to help solve problems based on varying degrees of problem specification.

The models implicitly or explicitly adopt some variation of the four-stage waterfall modules. partitioning the software development into phases such as analysis, design, coding, and maintenance although the strict linearity of the sequence of stages may not be preserved. The models typically rely heavily on documentation and conceptual artifacts such as diagrams as tools for planning development monitoring its progress and assuring its quality.

The artifacts also provide a degree of traceability for the entire development process, which is a precondition for system testing, modification, and maintenance as well as for process improvement.

The use of requirements engineering necessitates user or stakeholder involvement to ensure that the software product is a valid solution to the underlying problem; however, the level of stakeholder involvement varies considerably across the approaches.

Because software development strategies are needed specifically for solving nontrivial problems, the process models also require some type of project management to manage the complexity of the development process efficiently.

The problems addressed by requirements engineering and software developrl'lent are in busi ess or organizational contexts in·which the bottom line is to produce a profitable software solution that satisfies customer needs in a cost-effective manner and with appropriate quality. An efficient solution to the problem adds economic value to the organization.

The economic success of an application is measured in terms of metrics such as profit maximization, cost reduction, or customer satisfaction. These economic goals are reflected or represented in software process models in terms of project deadlines, budget constraints, and the efficient use of resources.

The shared characteristics of software process models reflect the shared human, technical, and economic constraints under which the models operate as they try to guide development projects in mapping application problems to the software-driven solution using an orchestrated set of tasks. This chapter briefly considers how these factors have persistently affected process models:

The need for a well-defined problem definition as an input to the software development process underlines the need to use requirements engineering in process models. Indeed, the need for a well-defined problem definition is what distinguishes the pre-software-engineering era .in which code-and-fix approaches prevailed from that in which well-engineered solutions are derived from well-understood problems. Also, increasing emphasis has been put on clear problem definition combined with increasing user involvement; the problems are recognized as user problems regardless of whether the user is internal or external to an organization

The tasks needed to produce a well-en entered solution define the second shared factor. Although the nomenclature and details of task decomposition differ, the analysis-design-coding-testing maintenance paradigm appears in most models. However, the relationships between the tasks vary substantially, with tasks sequential in some models, iterative in others, functionally independent or related by transformations, and static or dynamic.

The third shared factor is the role that stakeholders play throughout the ct.ex.eloi>ment process Stakeholders can range from users of the software product under development to individuals who decide on the system's requirements to system developers. This factor represents the people dimension of the process and affects every process phase, regardless of the degree of automation, because people are never absent from the process.

The fourth shared factor is the do -deliverables which are an essential feature of every software process model. Automated mechanisms like CASE tools may reduce the number of manual deliverables; however, these same tools can also increase the overall amount of documentation. The IBM Cleanroom Model is an example of a system in which automatic transfransformations across process phases are. using mathematical specification techniques rather than referencing manual artifacts. This results in a significant reduction of documentation but does not eliminate it.

The fifth shared characteristic is that the essential outcome of the development process is economic value because no market exists for economically infeasible software products. As a consequence, cost­ reduction and business benefits are the most common measures of effective software production, though this outcome may encompass effects beyond the direct economic impact of the product. The economic objective underscores the importance of project management in the process modeling because efficient utilization of resources requires effective project management.

A. decisive, historically driven phenomenon that has affected the definition of software models has been the recognition or discovery over time of a variety of principles or best practices for software development that have subsequently become embedded in development models. The recognition of such best practices is a recurrent theme in the evolution of every engineering field. Indeed, the best practices in each field often echo those in other fields.

Perhaps the most basic best practice or principle is what is called separation of concerns, which recommends intellectually segregating from one another the consideration of different problem-solving issues. This principle is reflected in the separate stages of the software life cycle, each of which focuses on a different part of the development problem. The life-cycle stages also reflect the practice of deferring decisions wherever possible to keep the development options as flexible as possible.

For example, system design decisions are deferred until the issues of problem analysis and specification are clarified, and so on. Another best practice, related to the pivotal role of users, is to focus on the underlying product objectives, concentrating on the goals of stakeholders rather than prematurely examining functional mechanisms for achieving those objectives.

The application of use cases during requirements analysis has also become a recognized best practice in more recent models and is prominently embedded in development models like the Rational Unified Process. Of course, the stakeholder goals should drive the identification of the use cases; these goals are more negative about what a product should do than of the expected tasks a system should perform because goals are more immediately related to stakeholder intent (Blank 2004).

Some specific best practices have been recognized for the systems analysis stage. For example, in the case in which the system to be developed is intended to replace an existing system, best practice recommends not modeling the design of the computerized system on the existing (nonautomated) system. Otherwise, one is likely to reify the structure of the existing system, whose functions could probably be provided more effectively using a design created with computer support in mind. The reason for this is that in-place systems evolving to reflect or adapt to the extant technological, human, and organizational context; a move to (increased) computerization is almost certain to benefit from a very different system or workflow architecture.

A notable instance of this practice is related to the increasing preference for flat organizational hierarchies. The desired flattening can be achieved by eliminating or streamlining intermediate organizational layers using computer support - a highly important design strategy called disintermediation. Disintermediation refers to the elimination or reduction of third-party intermediaries between the client or customer and the server or supplier of goods or services. Such a supply-chain compression of intermediaries is prominently applied on the Internet. Disintermediation is widely recognized as a major factor in the productivity increases that have resulted from computerization.

The variation in their shared characteristics is the most important source of variation among the software process models.

However, in addition to their shared elements, process models also exhibit several significant differences rooted in factors like the enabling technology underlying the model; the nature of the problems addressed or the problem-solving approach adopted; interdisciplinary considerations, etc. A context diagram illustrating the important factors affecting the diversity of process models.

The historical evolution of models has played a major role in how models have diversified over time. Naturally, ideas about how to define models evolved, with later approaches building on earlier ones. Significantly, technological advances enabled new approaches.

For example, RAD (Rapid Application Development) was enabled by the introduction of CASE tools a technique, and the development of the Internet-enabled or accelerated web-based approaches such as the open-source movement. Indeed, some models have been based on enabling technology as the critical factor.

Models have also reflected underlying problem-solving approaches and not just the general character of the problems.

For example, some approaches were based on structured design and others on object-oriented design; some were linear and others iterative; some used sequential workflows and others concurrent workflows. Dependency on the characteristics of the problem-solving methodology naturally affects the kinds of solutions produced because the problem-solving approach adopted by a developer affects how the problem is modeled.

Mahira  khanna

Mahira khanna

I have the skills you need for you company blog, website, or other content materials

If felt valuable to you, feel free to share it.


Report Response