The Software Development Life Cycle, or SDLC for short, which includes important stages that can be categorized into planning, implementation, and maintenance of the system solution, has established itself as the de facto process for years to help build information systems, systems engineering, and software engineering from the ground up. This article will examine the Software Development Life Cycle (SDLC), specifically the analysis phase.
Since its standardised phases, the SDLC has become increasingly important because it allows businesses to fulfill the needs of today’s fast-paced, complicated, and financially constrained markets.
Let’s begin our description of the analysis part of SDLC by defining what a system is. The collection, processing, and presentation of data is the job of a system, which is defined by industry standards as a collection of hardware, software, and human resources that carry out these tasks.
The SDLC contributes to the system’s realization in that environment. The answer to the question of why it is crucial to create and run information systems in a cycle can be found in the ongoing changes in the environment in which the system is situated and how those changes affect the system’s performance.
Upgrades in hardware, software, user requirements, the volume of information in the business environment and domain areas, and other factors are all part of the system’s life cycle, which also includes implementation and maintenance. Of course, more phases are now involved due to iterative processes and shifting business requirements, such as analysis, design, development, testing, and decommissioning or transition to a new information system. Each of these phases has grown in importance and can be used depending on the specifics of each project.
The Agile methodology has become the standard for software development projects because of how well it helps iterative and flexible creation of products that better meet the changing needs of today’s information systems. Iterative frameworks and phased approaches are two ways in which the Agile methodology and the software development life cycle (SDLC) can coexist.
Therefore, each person working on the project will be responsible for a distinct task during each stage. The analysis phase in SDLC is explored in greater detail here. But first, let’s take a look at system development life cycle’s benefits.
Among the many fundamental guidelines for creating software, simplifying it is a must. The SDLC method does this by breaking down huge projects into a series of smaller ones that can be more easily monitored and completed. The defined phases of the SDLC allow everyone participating in the project to have greater input and effectively manage it.
Having an SDLC in place when developing software is also valuable because it facilitates the transition from an idea to a fully formed, functional, and operational system. Activities such as process and procedure development, change management, policy development, user experience, impact, and adherence to security regulations are all included in the SDLC’s coverage of the operational and technical aspects of building software.
Furthermore, the SDLC process facilitates forethought and analysis of the organized phases and objectives of a particular project, making it simpler to handle, delegate, and address. A comprehensive plan is invaluable to define costs and staffing decisions, provide clear goals and deliverables, measure performance, and validate each phase of the life cycle to improve quality. Goal-oriented processes don’t adhere to a one-size-fits-all methodology but are instead responsive and quick to adapt to changing user and requirement needs.
The next step in our SDLC education is to learn all there is to know about the analysis phase.
The analysis phase in SDLC is where a thorough examination is done to get a clear understanding of the business requirements as outlined in the Business Case and Scope documents. System specifications are organized and studied. This can be accomplished by asking inquiries like the ones below:
Product demonstrations, jurisdictional scans, sample RFPs/BRDs from other jurisdictions, and industry research could all be done to help with requirements gathering. The definition and progressive elaboration of discrete requirements take place in conjunction with a series of requirement-gathering workshops. The decision-makers for the client and other important project stakeholders review and accept these requirements once they have been precisely defined.
Analysis Stages
Establish new system goals:
The analyst is aware of the information’s nature and how the system’s necessary software operates. The analyst conducts a quick review of the requirements and makes an effort to analyze the system’s performance. Additionally, he makes sure he has access to enough data and materials to build the necessary system.
Without regard to the means by which they will be achieved, the system’s needs are specified during the analysis phase. The customer’s issue is outlined at this stage. At the conclusion of this stage, a requirement document will have been produced as the deliverable result. In an ideal world, this paper would provide a detailed and precise description of the structure’s intended function. This analysis is the “what” stage. By defining objectives and interactions at a level abstracted from the implementation details, the requirement document strives to capture the requirements from the customer’s point of view. The requirements document could be written in a mathematically formal language. It is customary for the requirement document to be written in English or another international language. Information at a higher level of description is specified in the requirement document, rather than the architectural or implementation details. In this context, high-level descriptions include the problem statement, the customer’s expectations, and the success criteria. The distinction between high-level and in-depth explanations is often hazy.
If a particular engineering aspect needs to be detailed in great depth, the requirement document should provide that information. This is an unusual occurrence rather than standard practice. These exceptions occur for a variety of reasons, including maintaining consistency with other established systems, the availability of specific options, customer demands, and the establishment of a specific architecture vision at the requirement level. A limitation on the application’s picture size is an example of a low-level item that might be included in the requirement document. Other low-level details include the usage of a certain product line from a particular vendor, the use of an acknowledged standard from the computer industry, and so on.
A fundamental conflict exists between high and low levels of detail. The requirement document, which is independent of many details, states what the system should accomplish. The discovery process used to establish requirements during the analysis phase is more accurately described as a refinement process than a level-of-detail process. Top-down and bottom-up approaches necessitate a sharper distinction between high and low levels of detail. These details are refined as a result of interactive approaches.
Traditionally, the requirement document describes the items in the system as well as the actions that can be taken on them. In an object-based technology, where data and algorithms are hidden behind hierarchical-polymorphic methods, things could be expressed as objects. Alternatively, in a functional approach, things could be expressed as services accessing databases, where data is a fundamentally different concept than functions. In general, system descriptions can be much more general and not limited to a specific technology. In a broader sense, this document describes the ontology, or the noun and verb phrases that will serve as the foundation for defining the application-specific protocol.
The requirement descriptions of the system’s components and their behaviours do not imply an architectural design, but rather a description of the system’s components and their behaviours as seen through the eyes of the customer. These requirement descriptions are later translated into computer science primitives like lists, stacks, trees, graphs, algorithms, and data structures during the design phase. The use of a written human language is not required to describe the abstraction of the noun and verb phrases. The majority of written human languages are too ambiguous to convey the level of detail required to create a system. Alternative descriptive mechanisms built on mathematical logic are occasionally more appropriate, but a lot harder to implement. A scientific framework for precisely expressing information is provided by mathematical logic. In the real world, it is frequently impossible to give a precise description.
Once more, the requirement document needs to be very specific and clear about what needs to be built. Although the final mechanism to author such a document, whether formally or informally, has not yet been developed, existing techniques like CASE tools and tools based on mathematical logic have had some success. Data structures and algorithms are developed later in the design phase as a result of the crucial problem decomposition. The data structures and algorithms naturally divide into two groups as a result of a functional decomposition for a distributed environment. Examples include distributed client-server systems, in which the algorithms that manipulate the data reside on the client while the data is stored in a database on the server. Data structures and algorithms naturally combine to form objects with methods as a result of an object-based decomposition. The requirement documents ought to be separate from the method of decomposition. The analysis team creates the requirement document, which discusses and takes action on various topics. States, events, common usage scenarios, and uncommon usage scenarios should all be included in this document.
Here are a few of the SDLC most significant models:
The waterfall model of the software development life cycle (SDLC) is very popular. This approach compartmentalizes the entirety of the software development process into its component stages of the SDLC. Within the context of this SDLC model, the outputs of one phase serve as the inputs for the subsequent step. This SDLC model requires a lot of documentation because the earlier phases outline the tasks that must be completed in later phases.
There is no model apart from the incremental model that can be used. It is possible to dissect it into waterfall cycles, which is its most fundamental form. The requirements are initially segmented into their respective groups before the start of the project. The software development method for each group is modelled around the SDLC, which stands for the Systems Development Life Cycle. As the software development life cycle is iterated, additional functionality is added with each new release. This process continues until all criteria are satisfied. In this approach, each cycle acts as a new round of bug fixes for the prior software version. Development cycles can now overlap with the incremental model. It’s possible that the subsequent cycle will begin before the current one is completed.
The testing and development phases of this SDLC model are scheduled to run simultaneously. So, on one hand, we have the verification phases, and on the other hand, we have the validation phases. The V-Model is integrated through the encoding process.
Agile methodology is a process that encourages constant communication between developers and testers throughout the software development life cycle (SDLC) of any given project. With Agile, work is done in incremental bits. These releases are delivered in waves, with each wave lasting anywhere from one to three weeks.
The spiral model is a risk-based strategy for managing processes. When using this SDLC testing model, a team can more easily incorporate practices from multiple process models, including waterfall, incremental, and others. The advantages of both the waterfall and prototyping approaches have been incorporated into this model. The spiral method integrates concurrent design and development activities with rapid prototype iteration.
The big bang model prioritizes many different kinds of resources in software development and coding, and it does it with either no planning at all or very little planning. When the requirements are received, an understanding of them and their implementation will take place. This model functions optimally for moderately sized projects that have moderately sized development teams that collaborate. Additionally, it is helpful for software development initiatives at universities. It is an ideal model when the requirements are unknown or the final release date is unknown.
We have successfully learned the concept of analysis phase, along with other popular SDLC models. The project’s success relies heavily on the team’s ability to stick to a suitable life cycle. Because of this, management is simplified. The advantages and disadvantages of using a particular software development life cycle model can vary greatly. Requirement (how well defined or vague it is), System Complexity, Project Size, Cost, Resource Limitation, etc. can all help narrow down the best model for a given project.
