What is the Software Development Life Cycle (SDLC)

Zia

2 Followers

Follow

May 16, 2024

-

0 sec read

261

0

0

0

Introduction

Software Development Life Cycle (SDLC) is a process applied to the development of a software product. This process consists of a sequence of activities or phases that govern the entire life cycle of software development. Although the phases may vary from project to project, however, the basic concept of SDLC remains the same.

SDLC process helps organizations plan their software development projects efficiently and allocate the right resources to the project.

SDLC is applied to build new software projects and also to enhance existing software. SDLC is applied right from when the project is planned and extends throughout the development phase until the software is installed or ready for deployment.

SDLC has to meet a company's business requirements which are as follows:

• High-quality software systems: The customer must get value for money. Companies should consider spending money on getting new software or updating existing software worthwhile. The benefits of a new system have to be quantified and compared with the cost of setting it up. This cost Vs. benefit ratio is also a measure of a project's success. However, developing high-quality software is costly. Developers and customers have to strike a balance between the desired level of quality and cost.
  
  
• Strong management control: Developers have to accurately estimate the time and resources needed to execute each project. Software projects may take years to complete, and the original requirements should still be applicable at the end of the development. Throughout a project, regular checks are made to see if it is on track. If not, then corrective measures need to be taken.
  
  
• Increased productivity: There may be multiple ways of approaching a software solution to a particular business challenge. Businesses and software developers have to choose the approach that yields maximum results for a given cost. If not, there may not be any actual advantage of implementing the solution.
  
  
  
  

Evolution of SDLC

The SDLC methodology did not come into existence directly. In the 1940s and 50s, there was a shift from purely mathematical or scientific coding applications to business applications. This meant that computers and programming were open to more general uses than just technical ones.

In the 1960s, there was a need for an analysis and design of the project in addition to the implementation. Some of the early analysis techniques were Accurately Defined Systems (ADS) and Time Automated Grid (TAG). However, these techniques were very complex and therefore not used widely. Later, some of the new principles were incorporated such as:

• Working backward from the desired output to determine the necessary input.
• Represent software structures graphically
• Capture requirements in a formal record.

Note - Capturing requirements refers to the process of identifying and understanding the exact purpose and scope of the project, including information gathered from customers or end-users, and using that information to build a specific product.

A new top-down approach then emerged which helped eliminate premature coding and focused on first the analysis, then the design, and finally on coding. This is how SDLC first made its appearance and was eventually made a practice in software development.

Need for SDLC

From the developer's perspective, SDLC ensures a quality software product. Using SDLC allows software developers to organize and streamline their tasks. SDLC also enables developers to estimate the time and cost of their projects accurately.

SDLC has become increasingly important today due to the following reasons:

• There is an increasing need for automation of different everyday services such as processing of bills, personal banking, ticket booking, and so on.
  
  
• As businesses evolve, their services also need to evolve, which in turn means better and more complex software.
  
  
• Software processes have to be designed to handle a wide variety of inputs at the interface level. For example, personal details are entered while booking tickets. The software should be able to process input and give expected output. A software application should work similarly for all users.
  
  
• There should be no errors in software, especially while used for sensitive purposes, such as updating medical records, no matter how often or number of times it is run
  
  
• Integrating software components with other parts of the application should be easy.
  
  
  
  

SDLC phases

A typical SDLC consists of the phases or key activities that have to be part of any software development activity.

1. Planning and Requirement Analysis

The SDLC starts with the Problem Definition phase wherein the client's problem is identified and understood.

The basic goal of requirement analysis is to gather requirements, that is, obtain a clear idea of the client requirements for the project to be developed. Requirement gathering involves conducting a preliminary meeting with the client to understand and analyze the client's needs. The different techniques used here are:

• Interviewing - It is an oft-used technique when an analyst tries to get information regarding a problem from managers, department heads, and functional heads. The analyst will ask the customer a set of context-free questions, which will lead to a basic understanding of their problem and the nature of the solution that is desired. The context-free questions can be:
  
  "Whom will the requirements cater to?"
  "What will be the economic benefit if we come out with a successful solution?"
  "Describe the environment in which the solution is to be used."
  "Are the questions that I have been putting up relevant to the problem that is on hand?"
  
  Such questions help to focus on the overall goals and get a better understanding of the problem, the customer, and the effectiveness of the meeting.
  
  
• Questionnaires - These are used when a wide spectrum of responses is required and the consultants need definite answers to certain questions related to the problem area. For instance, getting responses from workers at a factory site. This is an ideal situation for floating questionnaires as a lot of time can be taken up interviewing such a large group. Moreover, interviews could result in vague and varied responses.
  
  
• Record Reviews - This is a technique used in all projects. It is only when existing records are reviewed that an analyst can understand the data, its movement, and usage within an organization. This cuts down on the time spent asking people within the organization basic questions that relate to the day-to-day functioning of a system.
  
  
• Observation - Helps the analyst in detecting problems that exist in the current system. Users are either unaware of the problems or they are hesitant to talk about them to outsiders, thinking that they may be misinterpreted. Even when willing to talk about a problem, the user may ignore certain minute and delicate details, which may be of extreme importance to the analyst. Such problems may come to light when an analyst observes the way an organization functions.
  
  

Once the requirements have been gathered, the development team needs to examine and categorize them. They need to prioritize the requirements and give a solution stating which part of the system should be automated first so that a major part of the problem area can be taken care of.

2. Defining Requirements

Having identified the problem, it is time to start developing the system. The process of system development starts with System Analysis. It is known that 'A System is a collection of interrelated components that work together to achieve some common objective' and 'System Analysis is the specification of what the system is required to do'.

System Analysis is conducted with the following objectives in mind:

• Identification and analysis of customer needs
• System evaluation for feasibility
• Performing economic and technical analysis
• Allocating functions to manpower, database, hardware, Software, and other system elements
• Establishing cost and schedule constraints
• Creating a system definition that forms a foundation for all subsequent development activities
  
  

System Analysis is an art and needs immense patience backed by years of experience to get the desired system functionality and performance. System Analysis study normally conducts a feasibility study. based on its result, the translation phase of inputs into formally specified requirements is performed.

Feasibility Study:-

There is a very old story about a very capable tailor. Once he used all his skill and insight to stitch a beautiful coat. When a prospective buyer pointed out that the sleeve was rather short, the tailor nonchalantly replied that the coat was so beautiful, surely the gentleman wouldn't mind cutting his hand to fit into it!

Most of us in the computer industry are often accused of having a similar affliction. That automation is indeed the solution to most organizational problems, seems to be a foregone conclusion for many a systems engineer. It is to temper such an over-enthusiastic prescription of automation as a panacea to all problems that the Software Engineering practice has inbuilt checks and controls. One such first and foremost step is the Feasibility Study.

All projects are feasible- given unlimited resources and infinite time Hence, before proceeding to commit to a large expenditure that is involved in the development of a new system, any organization needs to be reasonably confident that the proposed system is indeed going to deliver the goods and solve the problems on hand within the expected schedules and costs. A feasibility study is a means of enabling this.

A feasibility study is conducted to find out whether the proposed system will be:

• Possible - to build it with the given technology and resources
• Affordable - given the time and cost constraints of the organization
• Acceptable - for use by the eventual users of the system

Feasibility study provides answers to troublesome questions like-"Can I undertake this project?" "What are my market constraints?", "What is competition in this field like?", "How do I price my product?", and "What benefits will accrue from this project?

A feasibility study is initiated by an organization, which feels there is a need for change in the current system of functioning. This need may be felt due to lapses in the current system that may have been brought to light, or the organization may wish to change its system to introduce better, more efficient systems. A feasibility study is needed to ascertain the pros and cons of instituting a new system.

The purposes of this study are to:

• Determine the need for change within an organization (need analysis)
  
  
• Study the effect of the change on the economics of the organization (cost-benefit analysis)
  
  
• Evaluate various technologies that can be used to implement the suggested change, given the cost and resource constraints of an organization (technical feasibility)
  
  
• Evaluate the legal procedures, if any, that should come into play to implement the suggested change (legal feasibility)
  
  
• Evaluate the various alternatives that will be thrown up about resolving the problems of an organization, and recommend the best-suited one (evaluating alternatives)
  

Based on the outcome of the feasibility study, the management decides to proceed to the next phase of requirement analysis.

Translation of Inputs:-

This phase translates these informal inputs from the users into a set of formally specified requirements. The process of requirement analysis helps to bridge the communication gap between the customer and the developer. The technical development team works with the customers and system end-users to identify the application domain, functions, services, performance capabilities, hardware constraints, and so on related to the system to be developed.

The requirements must be specified in the Requirement Specification Document (RSD).

The contents of the RSD are:

• Functional and performance requirements of a system
• Input-output formats
• Design constraints
  

After a system has been analyzed and its requirements determined, they must be placed in the context of the functions that will be ultimately incorporated into the system. Functional analysis relates to the precise definition of the functions and sub-functions to be performed by the system. The functions have certain performance requirements, as well as certain design constraints that have to be borne in mind.

Example: A car is to be developed for the middle-income group of the population. The initial study is conducted with the target group of the population. Requirements state that it must be an affordable vehicle, fuel efficient, easy to run, good braking system for heavy traffic manoeuvers, and compact size for easy parking. The proposed solution should consider:

• Functions of the car - power brakes, easy shift floor gear system, power steering
• Performance requirements - fuel-efficient engine to give 'x' miles per gallon
• Design constraints - the size of the chassis

Based on the given requirements and expected functionality, a suitable car is designed for the middle-income population.

3. Designing Architecture

One of the most important stages during the SDLC is the design stage. The process of design is intricate and complex, and its final goal is to produce a model or a prototype of the system that will eventually result in the proposed system. In this chapter, we will explore the basic concepts and principles that apply to software design.

Design can be defined as the process of applying various techniques and principles to define a device, process, or system in sufficient detail to permit its physical realization.

Design is an iterative process during which requirements are translated into an outline for constructing the software.

Software design is situated at the core of the software engineering process and is always applied irrespective of the software process model used.

The different elements are used to provide the information necessary to create a design model. These are as follows:

• Entity Relationship (ER) diagram
• Data Flow Diagram (DFD)
• Control Flow diagram
• Data dictionary

The design model comprises data design, architectural design, interface design, and procedural design. The information domain model created during analysis is transformed using Data design into the data structures necessary to implement the software. Entity Relationship (ER) diagrams and data dictionaries created during the analysis phase act as a source of information about data objects and relationships which will form the base for activities in data design.

• Architectural design - Defines the relationship among the major structural elements of the program. The modular framework of a program can be derived from the analysis model and the interaction of subsystems defined within the analysis model.
  
  
• Interface design - Describes how software communicates with systems that interoperate within it and with people who use it. Data and control flow diagrams provide the information required for interface design.
  
  
• Component-level design - Transforms structural elements of the program architecture into a procedural description of software components.
  
  

The following three characteristics of design have been suggested by McGlaughlin and they serve as a guide for the evaluation of a good design.

• The design must implement all the explicit requirements contained in the analysis model and it must accommodate all the implicit requirements desired by the customer.
  
  
• The design must be a guide that is easily understood by those who write code and for those who test and subsequently maintain the software.
  
  
• The design should provide a complete picture of the software, and address the data, and functional and behavioral domains from an implementation perspective.
  
  

Technical criteria to establish a good design can be summarized as follows:

• A design should exhibit a hierarchical organization that makes intelligent use of control among elements of software.
  
  
• A design should be modular, which means the software should be logically partitioned into elements that perform specific functions and sub-functions.
  
  
• A design should contain both data and procedural abstractions.
  
  
• A design should lead to interfaces that reduce the complexity of connections between modules and the external environment.
  
  
• A design should be derived using a repetitive method that is driven by information obtained during software requirements analysis.
  
  
  
  
  

4. Building or Construction

Life is never quite as simple as that! It is estimated that more than 80% of the problems encountered in software development projects are thrown up only at the time of software building or implementation. This is the phase where the actual coding of a software application takes place, and a product is built from scratch.

In the implementation phase, several activities running in parallel have to culminate. The implementation phase ensures that all these activities are provided converge at the right time and the right place without any delays on account of unforeseen problems, and that the software begins functioning as it should.

Besides systems and business issues, there are personal issues. Users are apprehensive of computers, 'afraid' of learning technology, fearful of technology-savvy juniors, fearful of being termed redundant, and so on. These emotional issues complicate the process of implementing a new system within an organization. Although not beyond redemption, these issues should be accorded due importance and handled accordingly.

Therefore, during the implementation phase, besides the physical implementation of hardware and software, the analyst has to more importantly ensure that the new system is implemented in the minds of the users and accepted by them.

Unlike the other phases, there are no standard methodologies for implementation. However, the SDLC. The specific approach adopted for implementation is largely dependent on the size of the organization, the nature of applications, and the standard practices that may have been evolved by the project team.

However, despite such individual variations, there are some kinds of standard activities to be performed during the implementation process:

• Creation of an Installation Plan
• Implementation of Physical Procedures
• Data Preparation and Conversion
• Conducting User Training
• Running the System
• Installation Plan

Preparing a detailed installation plan is the beginning of the implementation process. The installation plan includes schedules for:

• Purchase of hardware
• Preparation of site - wiring, providing for communication points, air conditioning, and so on
• Purchase of environmental software
• Installation of hardware and environmental software
• Installation of the developed software
• Training
  
  

Implementation of Physical Procedures:-

Physical Procedures are those that an organization will follow side by side with the automated system and which will complement its functioning. These procedures also spell a change from the past and have to be in place before the automated system is implemented. Some of these systems include changes in coding schemes or introduction of a coding scheme, switchover to changed input and output document formats, changes in the sequence of operations, and others.

The successful implementation of systems depends as much on the adaptability of the people using them, as it does on the quality of software, and hence the need for the use of Physical Procedures. Users need to adapt to the new way of functioning. For instance, in the old system of functioning, there would have been multiple paper copies of various documents, but in the new system, the paper copies have been eliminated. Documents are stored in one place within the computer and retrieved when required. Sometimes, users are so used to writing out documents that keying them into the computer is not secure enough for them, so many users may want to continue making documents manually too (at least initially). The absence of paper can create a vacuum and the users may need time to get used to this paperless concept. The best way to deal with this kind of user reluctance is to make them aware of the same and provide training on these changed procedures before implementing the new system.

Physical procedures are an important aspect of implementation because they spell the changeover from the old to the new system and require handling of user training on the same. Physical procedures are handled by spreading awareness of the new system through well-designed training programs and handling user queries skillfully and patiently.


Data Preparation and Conversion:-

Data preparation is normally the most time-consuming and tedious task in the implementation of most systems. During the implementation of a new system, all data backlog has to be transcribed to fit into the new formats and coding schemes, and errors are rigorously checked to ensure no loss of information.

Data conversion is the process of converting data from the old system into a format required by the new, automated system. This usually amounts to creating the master database and entering the master data in the record formats that have been designed for the system, from the documents that exist in the system.

Organizations will not want data entry people running around for data as it shifts their concentration from what they are doing, which may induce errors in the data that is being entered. Data should be consolidated and validated by someone responsible before it is entered into the system.

Data conversion is required even if an automated system already exists. In such a case, a program may be written to read data from the existing format (if the old data format is readable by new software) into the new format. Alternatively, data has to be physically read from printed dumps of the old system master file and entered into the new system. Even if the old data formats are not compatible with the new DBMS formats, a small program can be written in a language like C, which can handle any type of data format.

This may become a cumbersome procedure and should be planned for in advance.

The process of data conversion requires the following:

• List of all existing files to be converted (for instance, some level of automation existed in the accounts function so some data required for our system's invoice-related databases will need to be converted from an existing file format into the new file format)
  
  
• List of new files to be created and data required for it (for example, if an existing system did not have a file for storing product discount details, but the new system requires it)
  
  
• List all new documents and procedures that go into use during conversion
  
  
• identify controls for the conversion process, how to determine that all records have been entered in the new database
  
  
• Prepare conversion schedule
  
  
• Assign responsibility for each task
  
  
  

Conducting User Training:-

The successful implementation of any software is dependent in good measure on the quality of training imparted to the users of the system. Different user groups need to be identified.

A Training needs analysis has to be done for each of these groups to find the kind of training that is required for each. Training Needs Analysis can be considered as the process of determining individual or group training needs for an organization.

There are usually several types of users within an organization, and all types of users do not need all kinds of training. Usually, two types of users can be identified for the system:

• Hands-on users
• End users
  
  
  

Running the System:-

The period of run varies from organization to organization and from application to application. Although there are no hard and fast rules for this phase, it is attempted to ensure that the following factors are looked into:

• There are no major faults in the package
• Important figures tally
• All modules are used and found satisfactory
• There is a fair amount of confidence amongst users in being able to use the software
  
  
  
  

5. Testing

Testing is very important in SDLC as the quality of the product depends on this phase. The efficiency of the testing phase can make or break a software product. Poor quality can lead to product failure and loss of money and business for the developers as well as the customers. The reputation and success of a software development company depend on how strong its quality assurance process is.

Testing is also called Quality Assurance (QA). The different types of testing conducted on the software are as follows:

• Unit testing: Refers to testing one component of the product. This is done by the developer after he or she finishes coding for that component. This makes sure that the component is working properly. This saves time as a component's code need not be passed to and fro between the tester and the developer.
  
  
• Sanity testing: This is done to test if all the components compile easily with each other. When multiple developers work on the same project, testing has to be done to make sure that all the components are in agreement with each other and there is no conflict.
  
  
• Regression or stress testing: This kind of testing happens over a longer period. Some software issues are thrown up only when the software has been run for a certain period. As it takes a lot of time, regression testing can be carried out continuously so that there is not much delay in the final product delivery.
  
  
• Functional testing: Refers to testing the software in its entirety to make sure it serves the purpose it was intended for. This is not done by developers, but by professional testers whose job it is to test software for functional and technical integrity.
  
  
  
  

6. Deployment and Maintenance

The process of software engineering does not stop with the delivery and installation of software but also includes maintenance activities.

Maintenance activities involve making enhancements to the software products developed in the earlier stages of the life cycle, adapting products to new environments, and correcting problems. Enhancement of the product may in turn involve providing new operational capabilities, improving the user screens and modes of interaction, and improving the performance of the system in general.

Adapting the product may require moving the project to a different machine or platform, or accommodating new protocols or even new hardware components such as an additional disk drive. To correct problems, we may need to modify the code and revalidate the software. It has been practically observed that maintenance activities account for a large portion of the system life cycle costs, even as much as 60-70 percent of the total costs set aside for the project. Software maintenance like software development requires a combination of managerial control and technical expertise.

Case Study

ABC Insurance Co. is planning to create a customer information system. The company feels this will help them track the customer's policy and profile details. The system will provide better visibility on plans that are currently the best sellers in the market, besides giving the marketing team the inputs to build on these plans. It will also provide them an opportunity to revisit the plans which are not doing well.

Michael Philips, an industry expert in Software modeling. is hired by the company to help them realize this goal.

Michael recognizes from the outset that this particular project would follow the stages of a traditional SDLC. Considering the current level of expertise in the organization, he also proposes that the testing of the application be outsourced to third-party vendors to minimize the turnaround time of the application and provide accurate test case results.

How will the SDLC phases look for this case?

Requirements Gathering and Analysis:-

The first step in the SDLC is to define the problem as part of the Analysis phase.

• The current approach of the company is to manually track the sales of the policies and also the customer profile and policy information. Before expansion, a major roadblock To the company was to automate its systems to better manage the overall business life cycle.

In the Requirements Analysis stage, special care is taken to ensure that the proposed system meets the management's objectives. The key requirements include:

• Customer profile and policy management
• Sales tracker
• Policy performance tracker
• Weekly and monthly sales reports
• Renewals status
• Customer service module to resolve customer issues
  
  
  

Designing Architecture:-

• Considering the scope of the application, Michael has to provide a detailed design of the scope and flow of the application.
• This requires designing DFDS, and flowcharts, defining the architecture and layout, deciding on the security policies and mechanisms, defining the access roles to the software, and the database design of the application.
  
  
  

Building and Testing:-

• In this phase, Michael has to guide a team of developers to code the software and build it on the initial framework that was designed in the design phase.
• At the same time, Michael also has to guide the third-party testing vendor to write test cases to validate the developed software.
• Once the software is coded, it is tested and necessary bug fixes are done.
• The software also undergoes unit testing, integration testing, and system testing.
  
  
  

Operations and Maintenance:-

• In this phase, the software is ready to be installed.
• Before that sufficient training is provided to the end-user team with demonstrations and their feedback is incorporated.
• Once the team is trained and comfortable with the new software, all the existing customer details are migrated manually into the system as a one-time activity.
• Any critical issues during this process are addressed and fixed immediately