Software process

SW Development: Activities, Processes, and Models

SW Development Activities

The goal of software development is to produce a software product. This is done by a sequence of human activities which are basically the same for every software product. We have to determine the requirements of the product, we design it, we code it, we test it and we release it to its user(s).

Of course, the requirements activity for the development of a little personal CD-Audio catalog and the same requirements activity for the development of the control software for an interplanetary rocket may be quite different in their approach, operations, methodology, documentation, and amount of work, but in both cases we will have an activity which deals with the product requirements. And the same applies for design, coding, testing and release activities.

So we may agree that, to develop a SW product, it is necessary to execute the following basic activities in a sequential manner:

  1. Requirements;
  2. Design;
  3. Coding (or Implementation);
  4. Testing;
  5. Release.

And why should we do them in a sequence? Because we cannot test something we did not designed and we cannot release something we did not implement (code).

Now, there will be some voices to say: “But I don't need a 'requirements activity' to code a CD-Audio personal catalog”.

This is simply not true – a developer may not need to document some requirements specifications for a simple CD-Audio catalog application, for personal use, written in MSAccess (for example), he or she may not even expressly need to thoroughly think about them beforehand, but to design and code the application, these requirements have to be clearly “stated” in the developer's head, at least.

And the same considerations apply for all the basic development activities – design, testing, etc.

But are these five basic activities enough to develop a SW product? The answer is: No, they are not enough. Even for very simple SW products we will need a little planning and other management activities, some logistical activities, and probably some other type of activities, as development environment maintenance (we should maintain our computer, the operating system, etc.), acquisitions (we may need to buy some ink for our printer), and maybe few others. And I still mentioned nothing about the concept development of a commercial software product to fit the targeted market, or about SW maintenance of legacy code.

The point I want to make in this section is that it is practically impossible to make a SW product worth this nomination without somehow performing these five activities: requirements, design, implementation, testing, and release. These activities may be undocumented, uncontrolled by any standards, and even hidden by some other activities, but they are still there for every SW product we are using.

SW Development Processes and Their Design

A process is a designed or spontaneously occurring sequence of operations which produce a result.

No SW engineering product to the date was the result of a real spontaneous process, whatever the hackers' community may say about it. So, the logical answer to our desired outcome - a high quality SW product - is a carefully designed and meticulously implemented SW development process.

Should this process be complicated too? No, “it should be as simple as possible, but not simpler” ☺[Note 1]. It should be tailored for the specific SW project, or at least for a specific type of project. And it should be also known to and applied by all the participants to the software development and auxiliary activities. (It is fashionable to call all these people stakeholders ...)

It should be very useful to have a general method for the design of any type of SW development process. Unfortunately such general method still have to be invented, to my knowledge. And, because a design method for the SW development process is missing, people are taking one of the existent SW standards and are “tailoring” them, usually omitting some of the standard's features that clearly do not apply to the their project's environment.

Blindly applying a process model or a development standard to our development process will most probably solve some of our development problems. ... And some tens of thousands of dollars and a few months later we will maintain the 'new' process and we will continue to look for other models and standards to solve the rest of our unsolved development and management problems.

So, are our models and standards bad? Not at all, but they should be taken at their face value – none of them is a silver bullet, even if they are almost presented as such by their inventors, supporters, or fanatics. The SW development models and standards present some important and useful principles and practices of our trade, but no software development standard or process model to the date addresses all the SW development issues.

This situation leaves to us only one healthy option: we should carefully analyze our problems, find their causes and then look into the standards and models (in all off them if possible) for useful principles and insights to solve our problems. And after finding these principles we should adapt them as working methods and practical procedures and integrate them in our development process.

This process should also be designed with another important criterion in our minds: it should be as simple as possible for the developers, to put on them as little “process” pressure and minimum overhead as is practically feasible. This simplicity has the main goal to let the developer develop the SW – to be creative, and to have fun doing it.

But what about SW development frameworks as CMMI or ISO 9000? Couldn't their literal application solve all our quality, costs and scheduling problems at once? I certainly doubt it. Of course, applying them will not hurt our professional capacity and our maturity as an organization but it will neither solve all our problems.

For example, if we have a strategic client which does not know what are his/her needs exactly, it will not help us to invest a few thousands hours of our developers' time budget, plus a few tens of thousands of dollars and upgrade from CMM Level 2 to CMM Level 4 in 12 months. Instead of this approach, we may try applying some prototyping and teamwork principles (XP [Note 2], JAD [Note 3]), combined with some version of incremental (or evolutionary) delivery. And this methods may solve our (and our client's) problem in 3 months, maybe – at much lower costs and greater satisfaction of all the parts involved.


  1. The expression is attributed to Albert Einstein.
  2. XP stands for EXtreme Programming.
  3. JAD is the abbreviation of Joint Application Development.

SW Development Models, Standards, and Frameworks (Software Process Technologies)

The “Code and Fix” Model

This is the model of developing computer software in the early days of the computers, when the software development was considered more like a magic art than an engineering discipline.

Even today, when the programs are simple enough or small enough to be kept in the developer's mind, we can use this “code and fix” procedure:

  1. Understand requirements;
  2. Go ahead and code the entire program or the testable module;
  3. After it passes compilation, test it;
  4. Fix the “bugs”;
  5. If there are too many “code & fix” loops, start again to code from the scratch;
  6. When finished, deliver the code.

Following this “natural” process model there were different attempts to define a more comprehensive model for software development, the most notable being the 9-Phase Software Development Model published by Herbert D. Benington in 1956 [8], which precluded the Waterfall Model.


careers | contact | dallya