Overview Of The Software Development Life Cycle Phases - IBM Mainframe

We have seen that there are a number of software life cycle models. But the purpose of this chapter is not to explore further on these life cycle models. There are certain phases that the software goes through before, during and after the development process. We will see those phases and examine each phase in detail. The when, why and how of these phases are taken care of by the life cycle models. The various phases or steps in the software development life cycle (SDLC) are:

  • Project start up
  • Requirements analysis and requirements specification
  • System Analysis Systems Design (High Level and Low Level (detailed) Design)
  • Development/Coding & Unit testing
  • System/Integration testing
  • Acceptance testing
  • Implementation
  • Project windup
  • Maintenance
  • Retirement

All the above phases will not be there in all projects. Also all the activities described in each phase will not be present in many projects. Depending on the size, nature and complexity of the project, many of the activities and even some phases might not be present. Also in many projects the activities could be performed in an informal manner. For example, small projects will not have a very detailed Requirements Definition Document (RDD) or Systems Analysis Document (SAD). Also in many projects the alpha and/or beta testing phases could be absent. The phases described below are for a fairly large project; but depending on the nature of the project and organizational policies, some of these phases might get clubbed together, omitted or may be practiced under a different name. Now, keeping this in mind, we will see the different phases of software development in a little more detail.

Project Start-Up

This phase is sort of a Curtain raiser for the project. The project team is formed and the project leader identified. The project is organized—modules identified, the key members are enlisted and the people who will carryout the support functions such as internal quality assurance, configuration management, etc. are identified. The senior members of the project team will sit together and prepare the project plan so as to ensure completion of the project within the cost, time and resource constraints based on the details available. The main tasks in this phase are:

Studying the project proposal and contract document (if it is a contracted work), estimation work papers and other documents available.

  • Obtaining clarification on matters such as scope, contractual obligations and client participation in the project, if required.
  • Defining the operational process for the project.
  • Deciding on the format and standards for documenting the project plan.
  • Documenting the project plan as per the structure and format decided upon.
  • This phase also sets up the hardware and software environment for the next phase covering the hardware, system software, standards and guidelines. The main tasks performed are:
  • Ensuring that the environment defined in the project plan is valid for the next phase and, if required, changing it.
  • For each resource that is defined as a part of the environment, its availability is checked. It is during this time that the requests are raised to the respective support groups for supplying or arranging the required resources.
  • Ensuring that the required hardware and software are in place.
  • Testing the environment, if required.
  • Obtaining the working space, machines and other infrastructure requirements for the team members.
  • Adding new procedures or modifying current procedures to be followed by the team.

Most organizations will have their own software development standards and guidelines, and if the work is done for a particular client, the project will have to follow the standards of that company. In cases where project standards are not available, they must be developed and finalized during this phase. The standards for various phases include:

  • Documentation standard for Requirements Definition Document (RDD)
  • Documentation standard for Systems Analysis Document (SAD)
  • Guidelines for various analysis techniques such as data modeling and process modeling
  • Documentation standard for HLD Document
  • Database and file design standards
  • Documentation standard for Test Plans and Test Specifications
  • Documentation standard for User Documents
  • Documentation Standard for LLD Document
  • Documentation Standard for Unit Test Plans and Specifications
  • Programming Standard?
  • Documentation Standard for Defect Logs
  • System Test Plan Standards
  • Test Data Preparation Standards
  • Testing Standards

The output of this phase is the project plan, and the standards for the next phases. This phase is done usually by a high-level team comprising the project leader, management representatives, SCM manager, support team representatives and so on.

Requirements Analysis and Requirements Specification

This is the phase in which the user requirements and specifications are captured and documented. During this phase, a detailed plan for the phase is prepared. The high level activities for this phase are expanded so that each activity spans not more than one or two person-weeks. The dependencies between the various activities of this module are identified and the activities are scheduled. Plans for housekeeping activities like backup/recovery and security are formulated. The resources required are estimated and the team members are allocated the tasks.

One of the main tasks of this phase is to understand the current system (manual or computerized). This is not applicable for a new product development project where the task is to understand the functions that the software is supposed to perform. The task should be undertaken with a view to examining its adequacy and identifying problem areas. The main tasks that are performed in this phase understand the current system by discussing with the users and studying the documentation available. The main areas that are studied are organization objectives, activities, procedures, rules and standards, files and interfaces and so on.

Every existing system, whether manual or computerized, will have some problems or inadequacies. That is why it is being redesigned. Even if the system is functioning smoothly, there could be areas that could be improved in a computerized system. These existing problems and constraints are identified. The existing system, problems and constraints are documented for future reference and the findings are discussed with the client or user.

The next step in this phase is the definition of the user requirements. The main activities that are performed in this phase are diagnosing existing problems and defining the user requirements. To do this, the context of the problems has to be understood, the scope of the problems has to be assessed and the user requirements, application requirements and information requirements have to be determined.

Once the user requirements have been defined, the next step in this phase is the preparation of the Requirements Definition Document (RDD). The RDD is sometimes known as the Software Requirements Specification (SRS). Once the initial draft of the RDD is created, it is given to all the parties of the software project—users, clients, project team and the support functions. After incorporating the suggestions from all quarters, the final RDD is prepared.

The output of this phase is the documentation of the existing system, and the RDD. The requirements analysis and the preparation of RDD will be usually done by the system analysts in collaboration with the users.

Systems Analysis

In the system analysis phase the proposed system is defined after analyzing various alternatives. The main tasks that are performed in this phase are:

  • Study the approved RDD.
  • Generate alternatives (solutions or designs) for the proposed system. To do this:
    1. Access prior knowledge
    2. Customize candidate solutions
    3. Partition the system
    4. Prototype the system if necessary

Evaluate alternatives. Perform impact or cost-benefit analysis for:

  • Tangible cost (one time and recurring cost, like cost of the tools used in the project)
    1. Intangible cost (procedural and personnel related cost, like cost of training the employees on the tools that are to be used in the project)

Select an alternative.

Determine system requirements with respect to:

  • Reliability
  • Performance
  • Security
  • Back-up/restore Error recovery Other quality factors

Discuss the proposed system with the client

In some cases the project management may decide to develop a prototype of the system to demonstrate the understanding of the user requirements and the functionality that will be provided in the proposed system. Prototyping is required if lack of clear understanding of the user requirements is considered as a major risk in the project. Major activities in case of prototyping are:

  • Inquiries and reports to be provided
  • External interfaces to be provided.
  • Decide on the type of prototype, that is, whether it should be evolutionary or throwaway.
  • Decide on the software and hardware platforms and the tools to be used for developing the prototype, and set up the environment.
  • Build a prototype to meet the objectives set out.
  • Demonstrate the prototype to the client/users and obtain feedback.
  • Incorporate suggestions for improvement.

Once the prototype is developed and the feedback is obtained, the next step is to prepare the Systems Analysis Document (SAD), where the proposed system's functionality is documented. While preparing the SAD, a usability plan is prepared. Usability plan is prepared when the system that is being built uses commercial-off-the-shelf (COTS) packages for performing some tasks in the system. The usability plan will compare the available packages and will be of help in identifying the one that is best suited for the system— cost-effectiveness, amount of customization, method of integration of the selected package into the software system and so on. This plan is needed only if the system uses off-the-shelf packages.

During this phase the project plan and the RDD are refined and updated based on the project progress and changes in the scope of the project. The output of the Systems Analysis phase is the prototype (if developed), the SAD, the usability plan, the updated project plan and the RDD.

High Level Design

High Level Design provides an overview of the whole system identifying all its elements at some level of abstraction. This contrasts with Low level Design which elaborates the detailed design of each of these elements. The following steps are carried out in order to properly design the system:

  • Study SAD and ensure that requirements are understood so that the high-level design documents could be properly written.
  • Understand the features and capabilities of the hardware and software environments in which the proposed system is to be implemented.
  • Study standards and guidelines prepared for the HLD phase.
  • Establish design objectives, constraints, and guidelines with respect to usability, user interface, performance (response time, memory, throughput), reliability, design directives, storage, etc.

There are several purposes for high level design.

Preliminary design - In the preliminary stages of a software development the need is to size the project and to identify those parts of the project that might be risky or time consuming.

Design overview - As it proceeds, the need is to provide an overview of how the various sub-systems and components of the system fit together.

In both cases the high level should be a complete view of the entire system breaking it down into smaller parts that are more easily understood. To minimize the maintenance overhead as construction proceeds and the lower level is done it is best that high level design is only elaborated to the degree needed to satisfy these needs. Sometimes a prototype is developed to demonstrate the user interface design, screens, navigation and other features of the system. Developing a prototype in HLD phase is required if it is desired to demonstrate to the user, the design features of the system such as system architecture, user interfaces and system functionality. Sometimes a prototype is developed during the system analysis phase to demonstrate the understanding of the user requirements and the functionality that will be provided in the proposed system. If such a prototype exists, then this prototype is refined during the HLD phase to demonstrate the user interface design, screens, navigation and other features of the system.

It is in this phase that the system components like modules, programs, functions and routines are identified. The system components are identified hierarchically to the level required. The inputs and outputs of the system are defined. These include menus, screens, navigation, levels of help and help screens, reports, error messages, user interface and so on. The programs for each component are identified and classified. The programs can be classified as on-line/batch, reports, transactions, drivers, functions, libraries, etc. The performance requirements for each component are established and the components that can be reused are identified. The following items are produced as a part of this exercise:

  • System components list
  • User Interface Design
  • Programs and the interface definition between programs
  • Screens and report definitions
  • Screen navigation details
  • Help screens and messages

The next step in this phase is to define the system architecture. The system architecture is established in terms of security, data access, communication, restart/recovery, audit, and user interface. The system architecture deals with issues like whether the proposed system will be a client/server system or a mainframe system or will it be a geographically distributed system, what technology should be used, how the communications network should be set up and so on. The program dependencies and interfaces are identified and the system architecture for each class of programs is finalized and documented.

Another task in this phase is the finalization of the database/file design. The database/file design is derived from a data model or data store identified during analysis. This should include content, access and organization of the database/files. The contents of each of the tables/files in the database and the access path are defined. The necessary normalization of the database tables is performed to ensure processing efficiency. This step produces the Database Design Document (DDD).

The final task in this phase is the preparation of the HLD document. The HLD document is prepared as per documentation standards for HLD. The documents that have been prepared so far like the design objectives document, the system architecture document, the database design document, etc. are used as the input for the HLD document. The system test plan is a part of the HLD document. So while the HLD is compiled, the system test plan (STP) and system test specification (STS) are also prepared which will form part of the HLD document. The preparation of the initial draft of user documents such as user manual, capabilities manual and tutorials are started in this phase. So this phase produces the following documents:

  • High-level Design Document (HLD)
  • System Test Plan (STP) & System Test Specification (STS)
  • Initial draft of the user documents

All these documents produced in this phase are reviewed and if changes are required for any of the items produced during the earlier phases, then those items are updated.

Low Level Design or Detailed Design

Low Level Design (LLD) is like detailing the High Level Design (HLD). It defines the actual logic for each and every component of the system. Class diagrams with all the methods and relation between classes comes under LLD. Programs specs are covered under LLD.

LLD describes each and every module in an elaborate manner so that the programmer can directly code the program based on this. There will be at least 1 document for each module and there may be more for a module. The LLD will contain: - detailed functional logic of the module in pseudocode - database tables with all elements including their type and size - all interface details with complete API references(both requests and responses) - all dependency issues -error message listings - complete input and outputs for a module.

In this phase the copy libraries, common routines and program skeletons to be used are finalized. The HLD is analyzed to understand the system architecture, the components, programs and their interfaces. The standards prepared for LLD phase are studied. The component libraries to be used for each of the programs in the system are identified, so are the common routines and the input and output for these common routines. If program skeletons or templates are planned to be used for various types of programs, then the scope and contents of such skeletons and templates are decided. The specifications for the component libraries, common routines and skeletons are written.

The major task in this phase is writing the specification for each program in the system. Writing program specification is essential for projects involving development in procedural languages. For each program and reusable routine identified in the system, the program logic is determined, the structure chart is prepared (if necessary), the inputs, outputs, error messages and help messages are finalized and the program specification is prepared. As a part of the program specification, the Unit Test Specification (UTS) and Unit Test Plan (UTP) are prepared.

The last step of this phase is the preparation of the LLD document consisting of program specification for all the programs, component libraries, skeletons and templates of the system. At the end of this phase the project plan is updated, the RDD, SAD, HLD, STP, STS and the user documents are refined, based on the changes and additional information obtained during this phase.

Coding and Unit Testing

During this phase the programs, copy libraries, functions and other program elements are coded (or generated) and tested (unit testing). The main people who are involved in this phase are the developers/programmers, the analysts, the QA team and the testers. Among all the life cycle phases, this is the phase that will involve most number of people. The major activities during this phase are:

  • Study LLD document, test cases and data.
  • Include additional test cases if needed.
  • Code the programs as per the program specification.
  • If evolutionary prototyping approach is followed, the prototype should be refined to yield the final code.
  • Finalize all error and help messages.
  • Conduct unit test in accordance with UTS.
  • Record the test results.
  • Log the following unit test errors:
    1. Errors external to the program (where the error cannot be fixed in the program being tested)
    2. Errors in LLD and test specification
    3. Errors caused due to the standards adopted
    4. Errors in the reused code
  • Diagnose and fix the errors.
  • Update defect logs.
  • Initiate corrective action, as applicable. This might involve revisiting the earlier phases of SDLC.
  • Consolidate test results and findings, and record appropriately.

The output of this phase is the unit-tested programs containing the source code, the test results, the associated documentation, etc.

System Testing

This is the phase of the software development life cycle where the system testing or integration testing is carried out. The system test is done using the STP, STS and system test data. Many companies do alpha and/or beta testing also.

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Usually companies distribute the beta releases free of cost to the people who have enrolled for the beta testing program and in many cases the beta versions will be available for download from the company's web site. New products will have the alpha testing followed by the beta testing. But in the case of new versions of existing products, either alpha or beta testing is done. The tasks in this phase are:

  • Carry out system test according to the STP and STS. For alpha and beta testing there will be no test plans. In the case of alpha testing, the testers will be evaluating the acceptability of the new features or functionality and in the case of beta testing the testers will be trying to find out bugs or problems in the product.
  • Record the test results.
  • Log the test errors.
  • Diagnose and fix errors.
  • Update defect logs.
  • Initiate corrective action as applicable. This might involve revisiting earlier phases of SDLC.
  • Perform regression testing.
  • Consolidate and report test results and findings.

The major players involved in this stage are the QA team, the testers, the development team (for bug/problem fixing), the actual users of the system and so on. If alpha and/or beta testing are present, then the number of people who will be testing the system will increase dramatically. Once the project is successfully tested, audits are performed to ensure that the final product is complete and satisfies the specifications.

Acceptance Testing

Acceptance Testing is a level of the software testing process where a system is tested for acceptability.The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.

In this phase the project team prepares for the acceptance test by ensuring the availability and completeness of all work items needed for acceptance test and loading the acceptance test data. The project team will assist the client/customer in acceptance testing, recording the errors found and fixing them.

Phases, Output and People of the Software Development Life Cycle

Phases, Output and People of the Software Development Life Cycle


The implementation stage of a software development lifecycle starts when software developers get the baseline for their work on the project, which is provided by software architects. Software developers are tasked with coding the requirements of software design and the result of their work proceeds to the next stage of verification.

Project Windup

In this phase, the project wind-up activities are completed. All the resources acquired for the project are released. The main activities in this phase are:

  • Carry out project-end appraisals.
  • Debrief the project team, analyze the project performance and identify the success and failure reasons.
  • Release project team members, hardware and software resources.
  • Return client-supplied products, if any.
  • Ensure availability of project documentation copies in library.

Project Maintenance

Once the system is developed and tested, it is released to the users. From this point onwards the maintenance phase starts. Once people start using the system, many errors that escaped the testing will be found. The users might ask for new features and enhancements. It is the responsibility of the maintenance team to attend to these requests and to fix the bugs that are found. If the project has not followed any standards and does not have any documentation, then the job of maintaining the system can turn into one of the most difficult assignments that software professionals can have. A very good example of this is the Y2K projects, where people had to fix the problems in programs that were more than 20 to 30 years old, programs that had no documentation and that were developed without any programming standards and naming conventions.

The six software maintenance processes as:

  1. The implementation process contains software preparation and transition activities, such as the conception and creation of the maintenance plan; the preparation for handling problems identified during development; and the follow-up on product configuration management.
  2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and finally, obtain all the required authorizations to apply the modifications.
  3. The process considering the implementation of the modification itself.
  4. The process acceptance of the modification, by confirming the modified work with the individual who submitted the request in order to make sure the modification provided a solution.
  5. The migration process is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task.
  6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software.


The final phase in the life cycle of a software product or system is retirement. After many years of service, a stage is reached when any further maintenance would not be cost-effective. This could happen because the proposed changes are so drastic that the design as a whole would have to be changed and it would be cheaper to redesign and recode the entire product from scratch. The other reason is that, many changes may have been made to the original design that interdependencies have inadvertently been built into the product, so much so that there is real danger that even a small change to one module will have a drastic effect on the functionality of the product as a whole. Yet another reason is that the documentation may not have been adequately maintained, thus increasing the risk of a regression fault to the point where it would be safer to recode than to maintain. Another reason for retiring a software product is that technological advancements have made the existing system obsolete. The hardware on which the product runs have to be replaced by a different (more powerful and less expensive) machine with a different operating system and it is cheaper to rewrite from scratch than to modify the product. In each of these instances the current product is retired and a new version will be developed and the life cycle continues.

True retirement (removal of the product) is a rare event that occurs when a product has outgrown its usefulness. The client organization no longer requires the functionality provided by the product and it is finally removed from the computer on which it has been in operations mode for many years.

We have seen what is software development life cycle and the various phases involved in the software development process. All these phases may not be present in all the projects and as already mentioned the order in which the various steps are executed will vary. Most of the times, there will be some degree of overlap between the various phases. The software life cycle model that is adopted will determine these things. We have also seen the various activities and outputs of each phase. These aspects are summarized in the above figure.

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

IBM Mainframe Topics