Software Life Cycle & Software Development Life Cycle (SDLC) Model

Read Time:8 Minute, 12 Second

Software Life Cycle

All living organisms undergo a life cycle. For example when a seed is planted, it germinates, grows into a full tree, and finally dies.

The term software life cycle has been defined based on this concept of a biological life cycle to imply the different stages or phases over which a software evolves from an initial customer request for it, to a fully developed software, and finally to a stage where it is no longer useful to any user, and then it is discarded.

The life cycle of every software begins with a request for it by one or more customers. At this time, the customers are usually not clear about all the features that would be needed, neither can they completely describe the identified features in concrete terms, and can only vaguely describe what is needed.

The inception stage is the

stage where the customer feels a need for the software and forms rough ideas about the required features. A software evolves through a series of identifiable stages (also called phases) starting with the inception stage, on account of the development activities carried out by the developers, till it is fully developed and is released to the customers.

Once installed and made available for use, the users start to use the software. This signals the start of the operation (also called maintenance ) phase. When the users use the software, not only they request for fixing any failures that they might encounter, but also they continually suggest several improvements and modifications to the software.

Thus, the maintenance phase usually involves continually making changes to the software to accommodate the bug-fix and change requests from the user.

The operation phase is usually the longest of all phases and constitutes the useful life of a software. The software is retired, when the users do not find it any longer useful due to reasons such as changed business scenario, availability of a new software having improved features and working, changed computing platforms, etc. at last.

Based on this description, we can define the software life cycle as follows: The life cycle of a software represents the series of identifiable stages through which it evolves during its lifetime.

Software Development Life Cycle (SDLC) Model

In any systematic software development scenario, certain well-defined activities need to be performed by the development team and possibly by the customers as well, for the software to evolve from one stage to the next in its life cycle.

For example, for a software to evolve from the requirements specification stage to the design stage, the developers need to elicit requirements from the customers, analyse those requirements, and finally document the requirements in the form of an SRS document.

A software development life cycle (SDLC) model also called software life cycle model and software development process model describes the different activities that need to be carried out for the software to evolve in its life cycle.

An SDLC is represented graphically by drawing various stages of the life cycle and showing the transitions among the phases.

This graphical model is usually accompanied by a textual description of various activities that need to be carried out during a phase before that phase can be considered to be complete.

An SDLC graphically represents the different phases through which a software evolves. It is usually accompanied by a textual description of the different activities that need to be carried out during each phase.

Process Versus Methodology

Though the terms process and methodology are at times used interchangeably, there is a subtle difference between the two.

First, the term process has a broader scope and addresses either all the activities taking place during software development, or certain coarse grained activities such as design (e.g. design process), testing (test process), etc.

Again, a software process not only identifies the specific activities that need to be carried out, but may also prescribe certain methodology to carry out each and every activity.

On the other hand, a methodology prescribes a set of steps for carrying out a specific life cycle activity.

It may also include the rationale and philosophical assumptions behind the set of steps through which the activity is accomplished.

A software development process has a much broader scope as compared to a software development methodology.

A process usually describes all the activities starting from the inception of a software to its maintenance and retirement stages, or at least a chunk of activities in the life cycle. It also recommends specific methodologies for carrying out each activity.

In contrast, a methodology describes the steps to carry out only a single or at best a few individual activities.

Why use a development process?

The primary advantage of using a development process is that it encourages development of software in a systematic and disciplined manner.

Adhering to a process is especially important to the development of professional software needing team effort.

When software is developed by a team rather than by an individual programmer, use of a life cycle model becomes indispensable for successful completion of the project.

When a software is developed by a team, it is necessary to have a precise understanding among the team members as to—when to do what. In the absence of such an understanding, if each member at any time would do whatever activity he feels like doing. This would be an open invitation to developmental chaos and project failure. The use of a suitable life cycle model is crucial to the successful completion of a team-based development project.

Difference between programming-in-the-small and programming-in-the-large.

Programming-in-the-small refers to development of a toy program by a single programmer.

Whereas programming-in-the-large refers to development of a professional software through team effort. While development of a software of the former type could succeed even while an individual programmer uses a build and fix style of development, use of a suitable SDLC is essential for a professional software development project involving team effort to succeed.

Why document a development process?

It is not enough for an organisation to just have a well-defined development process, but the development process needs to be properly documented.

To understand the reason for this, let us consider that a development organisation does not document its development process.

In this case, its developers develop only an informal understanding of the development process.

An informal understanding of the development process among the team members can create several problems during development.

We have identified a few important problems that may crop up when a development process is not adequately documented. Those problems are as follows:

A documented process model ensures that every activity in the life cycle is accurately defined. Also, wherever necessary the methodologies for carrying out the respective activities are described.

Without documentation, the activities and their ordering tend to be loosely defined, leading to confusion and misinterpretation by different teams in the organisation.

For example, code reviews may informally and inadequately be carried out since there is no documented methodology as to how the code review should be done.

Another difficulty is that for loosely defined activities, the developers tend to use their subjective judgments. As an example, unless it is explicitly prescribed, the team members would subjectively decide as to whether the test cases should be designed just after the requirements phase, after the design phase, or after the coding phase. Also, they would debate whether the test cases should be documented at all and the rigour with it should be documented.

An undocumented process gives a clear indication to the members of the development teams about the lack of seriousness on the part of the management of the organisation about following the process.

Therefore, an undocumented process serves as a hint to the developers to loosely follow the process. The symptoms of an undocumented process are easily visible—designs are shabbily done, reviews are not carried out rigorously, etc.

A project team might often have to tailor a standard process model for use in a specific project. It is easier to tailor a documented process model, when it is required to modify certain activities or phases of the life cycle.

For example, consider a project situation that requires the testing activities to be outsourced to another organisation.

In this case, A documented process model would help to identify where exactly the required tailoring should occur. A documented process model is a mandatory requirement of the modern quality assurance standards such as ISO 9000 and SEI CMM.

This means that unless a software organisation has a documented process, it would not qualify for accreditation with any of the quality standards.

In the absence of a quality certification for the organisation, the customers would be suspicious of its capability of developing quality software and the organisation might find it difficult to win tenders for software development.

A documented development process forms a common understanding of the activities to be carried out among the software developers and helps them to develop software in a systematic and disciplined manner.

A documented development process model, besides preventing the misinterpretations that might occur when the development process is not adequately documented, also helps to identify inconsistencies, redundancies, and omissions in the development process.

Nowadays, good software development organisations normally document their development process in the form of a booklet.

They expect the developers recruited fresh to their organisation to first master their software development process during a short induction training that they are made to undergo.