Software Creation and Development Process - aghsoftech.com

The Process of Creating Software can become very complex, depending on its size, characteristics and criticality. Process is defined as the set of steps to follow to arrive at the solution of a problem or obtaining a product, in this particular case, to achieve a software product that solves a specific problem.

For example the creation of an operating system is a task that requires project, management, numerous resources and a whole disciplined work team.

At the other extreme, if it is a simple program (for example, solving a second order equation), it can be done by a single programmer (even amateur) easily. Thus, they are usually divided into three categories according to their size (lines of code) or cost: "small", "medium" and "large".

There are several methodologies to estimate it, one of the most popular is the COCOMO system that provides methods and software that calculates and provides an approximation of all production costs in a "software project" (hourly / man ratio, monetary cost , number of source lines according to language used, etc.).

Considering the large ones, it is necessary to perform complex tasks, both technical and managerial, a strong management and diverse analysis (among other things), the complexity of this has led to the development of a specific engineering to address its study and realization: known as Software Engineering.

While in the medium-sized, small teams (even a seasoned solitary programmer-analyst) can do the task. Although, always in medium and large cases (and sometimes also in some small ones, according to their complexity), certain stages must be followed that are necessary for the construction of the software. These stages, although they must exist, are flexible in their application, according to the methodology or development process chosen and used by the development team or by the solitary programmer-analyst (if applicable).

Software Development Processes have pre-established rules, and must be applied in the creation of medium and large software, since otherwise the project will not be able to complete or finish without accomplishing the intended objectives, and with variety of unacceptable failures (fail, in short). Among such processes, there are agile or light (XP example), heavy and slow (RUP example), and intermediate variants. They are usually applied according to the type and size of the software to be developed, at the discretion of the leader (if any) of the development team. Some of these processes are Extreme Programming (eXtreme Programming or XP), Rational Unified Process (RUP), Feature Driven Development (FDD), and so on.

Whatever the "process" used and applied to software development (RUP, FDD, XP, etc.), and almost independently of it, a "life cycle model" should always be applied.

It is estimated that of the total of large software projects undertaken, 28% fail, 46% fall into severe modifications that delay it and 26% are totally successful.

When a project fails, it is rarely due to technical failures, the main cause of failures and failures is the lack of application of a good methodology or development process. Among others, a strong trend, for a few decades, has been to improve methodologies or development processes, or to create new ones and to make computer professionals aware of their proper use. Usually the specialists in the study and development of these areas (methodologies) and related (such as models and even the management of the projects themselves) are software engineers, it is their orientation. Specialists in any other area of ​​computer development (analyst, programmer, computer scientist, computer engineer, systems engineer, etc.) usually apply their specialized knowledge but using models, paradigms and processes already elaborated.

It is common for the development of medium-sized software that the human teams involved apply "own methodologies", usually a hybrid of previous processes and sometimes with their own criteria.

The development process can involve numerous and varied tasks, from the administrative, technical and even management and management. But, almost rigorously, certain minimum stages are always fulfilled; which can be summarized as follows: Capture, elicitation, specification and analysis of requirements (ERS), Design, Coding, Testing (unit and integration), Installation and transition to production andMaintenance.

In the previous stages they may slightly vary their names, or be more global, or conversely, be more refined; for example to indicate as a single phase (for documentary and interpretive purposes) of "analysis and design"; or indicate as 'implementation' what is said as 'coding'; but strictly speaking, all exist and include, basically, the same specific tasks.

Models of Process or Life Cycle

For each of the phases or stages listed in the previous item, there are sub-stages (or tasks). The process model or life cycle model used for development, defines the order of the tasks or activities involved, also defines the coordination between them, and their link and feedback. Among the best known are: cascade or sequential model, spiral model, incremental iterative model. Of the above there are some variants or alternatives, more or less attractive according to the application required and its requirements.

Cascade Model

This, although more commonly known as cascade model is also called Classic Model, traditional Model or sequential linear Model.

The pure cascade model is hardly used as such, as this would imply a prior and absolute knowledge of the requirements, the non-volatility of the same (or rigidity) and subsequent stages free of errors; this could only be applicable to small and small systems to be developed. In these circumstances, the passage from one stage to another of those mentioned would be without return, for example going from the design to the codification would imply an exact design and without errors or probable modification or evolution: "code designed without errors, there will be at all future variants'. This is utopian; since intrinsically the software is of a changing evolutionary nature and hardly error free, both during its development and during its operative life. 

Any change during the execution of any one of the stages in this sequential model would imply restarting from the beginning the entire complete cycle, which would result in high time and development costs. However, the cascade model in some of its variants is one of the most widely used, for its efficiency and simplicity, more than anything in small software and some medium-sized; but never (or very rarely) is used in its "pure form," as stated above. Instead, there is always some feedback between stages, which is neither completely predictable nor rigid; this gives opportunity to the development of software products in which there are certain uncertainties, changes or evolutions during the life cycle.

Evolutionary Models

The software evolves over time. The requirements of the user and the product usually change as it develops. The market dates and competition make it impossible to wait to put on the market an absolutely complete product, so it is advisable to introduce a limited functional version in some way to relieve competitive pressures. In these or other similar situations, developers need models of progress that are designed to accommodate a temporal or progressive evolution, where the central requirements are known in advance, even if they are not well defined in detail.

In the cascade and cascaded model, the evolutionary nature of the software is not taken into account, it is considered as static, with well-known and defined requirements from the beginning. The evolutionary are iterative models, allow to develop ever more complete and complex versions, until reaching the desired final objective; even evolve further, during the operation phase. The models "incremental iterative" and "spiral" (among others) are two of the most well-known and used of the evolutionary type.

Incremental Iterative Model

In general terms, the general steps of the development process of a software product can be distinguished in Figure 4. In the selected life cycle model, these steps are clearly identified. The description of the system is essential to specify and make the different increments until reaching the global and final product. The concurrent activities (specification, development and validation) synthesize the detailed development of the increments, which will be done later.

Spiral Model

The Spiral Model was initially proposed by Barry Boehm. It is an evolutionary model that combines the iterative nature of the MCP model with the controlled and systematic aspects of the Cascade Model. It provides potential for rapid development of incremental versions. In the Spiral model the software is built in a series of incremental versions. In the first iterations the incremental version could be a model in paper or a prototype. In the last iterations, more and more complete versions of the designed system are produced.

The Spiral Model is divided into a number of Framework Activities, called "task regions". In general there are between three and six task regions (there are variants of the model). The regions defined in the model of the figure are:

Region 1 - Tasks required to establish communication between the client and the developer.
Region 2 - Tasks inherent to the definition of resources, time and other information related to the project.
Region 3 - Tasks necessary to evaluate technical and project management risks.
Region 4 - Tasks to build one or more representations of the software application.
Region 5 - Tasks to build the application, install it, test it and provide support to the user or client (eg documentation and practice).
Region 6 - Tasks to obtain the reaction of the client, according to the evaluation of what was created and installed in the previous cycles.

The activities listed for the framework are general and apply to any project, large, medium or small, complex or not. The regions that define these activities comprise a "set of tasks" of the work: this set should be adapted to the characteristics of the particular project to be undertaken. Note that the items listed in items 1 to 6 are sets of tasks, some of which normally depend on the project or development itself. Small projects require a low number of tasks and also a lot of formality. In major or critical projects, each task region contains tasks of the highest level of formality. In any case, protection activities are applied (for example, software configuration management, quality assurance, etc.).

At the beginning of the cycle, or evolutionary process, the engineering team revolves around the spiral (metaphorically speaking) beginning with the center (marked 1 in Figure 6) and in the sense indicated; the first circuit of the spiral can produce the development of a product specification; the following steps could generate a prototype and progressively more sophisticated versions of the software.

Each step in the planning region causes adjustments in the project plan; the cost and planning are fed back according to the client's evaluation. The project manager must adjust the number of iterations required to complete the development.

The spiral model can be adapted and applied throughout the software life cycle (in the classic model, or cascade, the process ends when the software is delivered).

An alternative view of the model can be observed by examining the "project entry point axis". Each of the circles (๏) fixed along the axis represent starting points of the different (related) projects; namely:

A concept development project begins at the beginning of the spiral, makes multiple iterations until it is completed.

If the above will be developed as a real product, another project will start: New Product Development. That will evolve with iterations until culminating.

Eventually and analogously, "product improvement" and product maintenance projects will be generated, with the necessary iterations in each area.

When the spiral is characterized in this way, it is operative until the software is removed, it may eventually be inactive (the process), but when a change occurs the process starts again at the appropriate entry point (eg, of the product").

The spiral model gives a realistic approach, which evolves just like software; it fits very well for large scale developments.

The Spiral uses the to reduce risks and allows to apply it in any stage of the evolution. It maintains the classic approach (cascade) but incorporates an iterative framework that better reflects reality.

This model requires considering technical risks at all stages of the project; applied should reduce them before they are a real problem.

The Evolutionary Model as the Spiral is particularly apt for the development of Operating Systems (complex); also in high risk or critical systems (eg aeronautical navigators and controllers) and in all those where strong management of the project and its risks, technical or management are necessary.

 

 

You May Also Like