Software Development Life Cycle Phases - IBM Mainframe

We have seen the different phases in the software development life cycle. We have also seen that depending on the development methodology, the sequence, duration, number of iterations, etc. of these phases will vary. We will now see an overview of these different phases. We will do so by using a real life analogy—the analogy of constructing a building. Like software development, the building construction also goes through several phases.

A person, a family or an organization decides to construct a building. It can be a home, an office, a shopping complex, an auditorium and so on. But first somebody has to bring up the idea of constructing the building. You have been living in a rented house for quite sometime and now you want a house of your own; the current office building might not be spacious enough or may not have the additional space for the new employees that you are planning to hire; the city does not have a good bookshop—the reasons that trigger the idea to construct could be many. But the fact remains that the concept is somebody's idea or inspiration or fulfillment of a need or capitalizing on a business opportunity. In this stage the idea to construct the building or house is just an abstract thought of a person or a group. It might have been communicated informally to others for comSOFTWARE DEVELOPMENT LIFE CYCLE PHASES

We have seen the different phases in the software development life cycle. We have also seen that depending on the development methodology, the sequence, duration, number of iterations, etc. of these phases will vary. We will now see an overview of these different phases. We will do so by using a real life analogy—the analogy of constructing a building. Like software development, the building construction also goes through several phases.

A person, a family or an organization decides to construct a building. It can be a home, an office, a shopping complex, an auditorium and so on. But first somebody has to bring up the idea of constructing the building. You have been living in a rented house for quite sometime and now you want a house of your own; the current office building might not be spacious enough or may not have the additional space for the new employees that you are planning to hire; the city does not have a good bookshop—the reasons that trigger the idea to construct could be many. But the fact remains that the concept is somebody's idea or inspiration or fulfillment of a need or capitalizing on a business opportunity. In this stage the idea to construct the building or house is just an abstract thought of a person or a group. It might have been communicated informally to others for comments and suggestions.

A similar phase in the software development life cycle is called the concept phase or concept exploration phase. Concept exploration phase is the period of time in the software development cycle during which the user needs are described and evaluated through documentation like statement of needs, advance planning report, feasibility studies, etc. It is in this phase that the user or developers identify the need for the software product and explore the possibility of developing it. This is usually the first phase in the software development life cycle.

Anybody wishing to put up a building will first try to determine whether the proposed structure is worth the money and effort it will require. Needs and benefits will be analyzed, preliminary cost and schedules estimated, specific functions and utility decided on, building land sought, legal implications examined and different modes of construction evaluated.

The purpose of the analysis stage for software is to determine whether it would be profitable to embark on the development of a new product. If so, we must assemble the necessary resources for that development effort. The analysis stage starts with conception of a new product. It is necessary to justify demand for software by market research or by a request for proposal from a potential client. It is also necessary to validate the desirability of the product in terms of goals, plans, and needs of the software organization and its personnel.

Once the need for the product is clear, one must define its nature in more detail. This is done by analyzing the user requirements, such as a general definition of the function of the product, its scope, the nature of its interface to the users, hardware requirements, existing products, the speed, the precision, the capacity and the cost of the product. This requirements analysis provides a basis for the rest of the analysis stage. It also allows us to decide whether such a product is within the reach of the organization's capabilities.

One cannot sensibly address software design without realizing that it springs from requirements, the customer's need that is to be satisfied or problem that is to be solved. In fact, when a software project gets into trouble, the difficult part is not solving the problem but understanding what the problem is. In order to develop the products that the client want and that meet the requirements, the requirements analysis phase should be done with great care and thoroughness. According to Brooks, the hardest single part of building a software system is deciding precisely what to build. No other part is as difficult. No other part of the work so ripples the resulting system if done wrong. No other part is more difficult to rectify later.

Understanding the needs to be met by the software is the first step toward its functional specification. This is usually accomplished by a process called Systems Analysis, in which the analysts consult with, interview and observe people in the user organization. The purpose is to understand fully the needs and constraints of the possible software solution, as well as the current structure and function of user operations.

Next step in the software development process is determining the costs and benefits of undertaking the project. Cost is made up of labor, new equipment purchase, diversion of existing facilities, purchase of software components from other sources and loss of opportunities (opportunity costs) because of the inability to undertake other projects. Benefits are composed of sales of the product, improvement of the organization's market stance because of the product, development of new skills within the organization and possibility of further product development based on this project. The risk factors or probabilities associated with cost and benefit calculations must be evaluated as well.

From the cost estimation, we will be able to tell with a reasonable level of accuracy, whether the project is profitable and if so how many people will be needed at what points in the project. Thus it is possible to produce a schedule of the project, together with plans for hiring or reallocating specific personnel and the acquisition of new hardware and software. If the cost-benefit analysis still looks promising, further planning is needed to establish management methods for the project. The final result will be a document of all the activities and results, as well as a proposal for the project. Returning to the building construction example, we must now specify what kind of building we want, number of rooms, what are the facilities and features that we need, the budget allocated for the construction, the amount of space that the building will require, the kind of materials that should be used, the general style and function of the structure, its safety and security provisions, etc. These are written down before we start to draw up blueprints. This document is an important part of the contract between the builder and the client.

The software requirements specification phase is the period of time in the software development life cycle during which the requirements for the software product are defined and documented. This phase crystallizes a precise description of the software's function, the exact nature of the environment in which it is to function, and the constraints on its performance. This description furnishes the basis of the contract, moral and legal, between the software developer and the user, and should be accompanied by a detailed plan for the acceptance test by which the purchaser will validate the software.

By firmly understanding the user's needs and environment, the development team can proceed with a detailed software specification. The process of developing the software specification is done in cooperation and consultation with the client. If there are no clients (i.e., if the product is developed for the general market) then the specification is developed in consultation with the marketing department of the organization. Nothing can be worse than producing the wrong software; so communication and mutual understanding among the various groups involved is crucial for the success of the project. It is also important to establish priorities, guidelines and constraints for the different functions to guide the development team. If all the needs of the client or the customer cannot be met initially, then that fact also should be mentioned.

In construction, the architect draws the picture of the proposed building and shows it to the client. The purpose of this drawing is to give the customer a feel for what the building will look from outside, so the customer can suggest any changes or improvements that he wants. In many cases the architect will create a scale model of the proposed building so the client can see a scaled down version of the final product. This scale model will help those clients who are not very good at understanding the architectural drawings and floor plans.

The architect's rendering has its counterpart in the external design of the software, which describes exactly how the software will interact with its environment. The user interface, the definition of command languages, the range of acceptable input, etc., will form part of the external design. During the external design phase, the software analysts might develop a prototype of the proposed system, so that the client can see how the system will look like when it is finished. A prototype is a preliminary model of the system that serves as a model for the later stages or the final and complete version of the system. Prototyping is a software development technique in which a preliminary version of part of or the entire software is developed to give the users a better understanding of the system and to facilitate better feedback, determine feasibility or investigate timing or other issues regarding the development process. External design starts during the analysis, continues in parallel with the specification stage and may even extend into later design stages. It is very important to avoid changes of the specifications after they are complete.

Once the initial drawings (and/or the scale model) are finished and the customer is satisfied with the look and feel of the building, the architect will now proceed with a preliminary design, which shows the placement, the relationship and size of major areas and functions within the structure. For example, he will decide the location of corridors, doors, windows, etc., which rooms will share a common corridor, and what needs would be served by each part of the building.

A software engineer also creates a preliminary design of a software product. This design defines the general structure of the software, the major modules, the functions provided by each module, the internal data-streams and stores that make up the interface between the modules. Here one point to be remembered is that, the software engineer must resist the temptation to include too much specific detail in the preliminary design. To do otherwise is to give up flexibility that is valuable at this point.

After the preliminary design, the architect prepares the detailed blueprints for the building. Here, he or she gives the exact dimensions of each part of the structure, the placement of doors, the thickness of the walls, etc. Attention shifts from the conceptual structure with its interrelationships to the actual method of building it. Similarly a software engineer carries out the detailed design of the product by specifying the algorithms and data structures that make up the interior of modules. Usually there are many choices possible, but from the different available alternatives, the one, which offers greatest efficiency, simplicity, functionality, and availability, is selected based on the relative importance of these criteria. Besides the system design document, the detailed design stage should produce:

  • A first draft of the user's manual that is dependent on the external design
  • An integration or system test plan, which depends on the architectural design
  • Unit test plans which depends on the detailed design

The blueprint or the detailed architectural design is converted into a building by a team made up of carpenters, plumbers, electricians and other specialists, supervisors, and a number of unskilled construction workers.

In a similar fashion, the development (coding) of software product is also done. Here the design is converted into code. There are several issues in development that are independent of the specific details that are to be coded. For example, the choice of the programming language may have a significant effect on the ease of coding. Standards for in-line documentation will improve the maintainability. Code optimization will improve the performance.

Another important factor to be considered in the development is the multi-platform support. Most products are meant to run in a variety of hardware and software configurations, requiring many different versions. In order to produce a number of different implementations, the specifications and the design should be as generic and portable as possible.

Besides the actual code, the coding phase may produce modifications of specifications, design documentation and unit tests to accommodate errors that have been detected. The final version of the user documentation like user manuals, installation guides, training materials, error guides, etc. will be produced.

When a construction work is being carried out, the work is monitored by supervisors, so as to ensure that the work is defect free, is of the required quality and meets the specifications. Local governments employ building inspectors, who inspect a building (along with the architect) before giving the final approval. Finally the purchaser of the building is likely to make an acceptance tour, looking for evident defects in finish and completion.

Dependability is one of the most important attributes of good software. Good specification, design and development practices should reduce the number of errors in the product; but it is foolish to assume any software to be coded defect free and perfect. Testing is conducted to find and eliminate errors. In most cases testing involves more effort than the coding. Refusal to accept this fact and not giving enough time for the testing phase is the cause of project overruns and undependable software. The testing stage goes beyond simply running the system to see whether it works and looks right. There are different types of testing methodologies, alpha and beta testing, black-box and white box testing, top-down and bottoms-up testing, pragmatic testing, etc. Whatever be the methodology used, testing can be broadly classified into three kinds— unit, integration and system testing.

  • Unit testing investigates the correctness of the individual modules and looks for structural weaknesses in them.
  • Integration tests the interactions of the different modules in the system and the functionality of the integrated subsystems.

System and acceptance tests determine whether the final product complies with the user's original specifications. The system testing is done by the quality assurance team or an external auditing authority. The acceptance testing is done by the user or the customer.

Plans for these tests should include not only the data and actions to be used in testing, but also the acceptable responses of the software. Testing should be carried out by those individuals responsible for the design and coding of the software as well as the specially designated quality assurance personnel and the representatives of the client. The primary objective of testing is to uncover and correct the defects in the specification design or code, so that all the documentation produced till then and that are affected by the changes made during the testing could be updated.

Now it is time to move into the new building. Furnishings must be purchased, minor mismatches should be corrected, and the builder can review the building process to evaluate what went wrong and how the construction could have been made more efficient.

When software has been tested and accepted, it is ready for use. But it should be installed at the customer's site. This may seem to be simply copying the files and manuals. However, it is necessary to coordinate with the installation of the new hardware as well. Often there will be some amount of end-user training. At this point, a return to the acceptance test may be needed to ensure that the software works well in the client's environment as it did at the developers. After training, while the client moves into the new system, the software organization has to maintain a high degree of support to the client. This is a critical time, and problems are sure to crop up. Even if the software organization is not responsible for the difficulties, their software is sure to be blamed, if they are unable to provide support.

It is very tempting for the development team to install the product and then forget it. However, a project debriefing process is vital to evaluate the successes and failures of the project. The debriefing is done as part of the project windup phase. The purpose of these debriefing sessions is to document what has been learned from the project in order to provide a basis for future efforts. This record is called a project legacy or project completion report. This will form the basis for the corporate memory, so that every time the 'reinventing the wheel' can be avoided.

The client will need support throughout the entire useful lifetime of the software. Naturally, the level of support and effort involved decreases with time as the users become experts and the client organization adapts to the new software. However, some problems will arise, requiring some modification of the product. This maintenance effort revisits all the other stages of the software life cycle. Changes may be required to eliminate errors, to provide additional functionality or to allow the product to be used in a new environment. Each modification requires planning, specification, design, coding, testing, installation, and so on.

Having discussed about the software life cycle, a natural question that arises is 'when does software die?' or 'when is a software product retired?' After installation, and as time passes, the utility of the software decreases, either in absolute terms or relative to other options available. Repeated maintenance actions tend to complicate the original clean and simple, design of the product. Additional maintenance may not be economical. The retirement phase of a software product is the period of time in the software life cycle during which support for the product is terminated. But predicting the life of a software product is very difficult. It depends on a lot of environmental factors such as the advancements in technology, new and cheaper competitive products, etc. Sometimes a software product may 'live' for many years, but sometimes the life span can be only a few months and in some cases it might not be used at all.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics