Which Phase Is Not Available In Software Life Cycle

To maintain structured software engineering, there is no alternative to the software development life cycle. In the process of software development, there are some phases. All phases are working before proceeding to the next phase. There are several terms or concepts moving around that seem to belong to SDLC but do not officially fit within its framework. But the question is, which phase is not available in software life cycle?

One such concept is the “Abstraction.”

In this blog, we will discuss it briefly why it's not present and the importance of these phases. Read this informative blog to learn all the details. 

Let's start. 

Software Development Life Cycle - A Quick Recap 

In short, this is the most cost-effective and highly time-efficient method the development team uses to design and build quality products. The ultimate goal of the SDLC project is to minimise the project risk and maintain customer satisfaction in the long run. SDLC also ensures that after the project, it will be a good investment for the investor and gain some actual revenue for the organization. Normally, the SDLC has seven different phases, including :

• Planning
• Systems Analysis & Requirements
• Systems Design
• Development
• Integration & Testing
• Implementation
• Operations & Maintenance

These steps are generally found in models like Waterfall, Agile, Spiral, and V-Model. Despite agile vs waterfall differences, each model adheres to the basic principles of these phases. 

But where does abstraction come in, or what does abstractions mean? Let's check some basics first. 

What is Abstraction in SDLC

Abstraction is a fundamental concept in computer science and the software development life cycle. If we explain the word in the short term, it will be clear to you. Abstraction is like handling complexity by hiding the unnecessary details and exposing only the essential features. If we define it in programming, then it is something like :

It's a function that performs calculations but hides its algorithm from the caller, which is an abstraction. In another way, an API endpoint returns user data but does not expose the backend logic. 

So, in short :

• Abstraction simplifies complexity
• It focuses on the “what,” not the “how”
• Allows different parts of the software to communicate cleanly

Developers identify the software's core functionalities. They try to model the real-world problem into abstract components, deciding what details should be hidden and what interfaces or modules should be exposed.

It may include:

• Class and object model(in object-oriented design)

• Interface design

• Data model(entities and relationships)

• High-level system architecture

Technically, the abstraction “phase” involves mental modeling, conceptual planning, and structuring the software in abstract terms before proceeding to concrete code or design documents. 

Some educators, developers, or theoretical discussions object to calling abstraction a proper phase. Because of this, abstraction is informally defined as a mental or preparatory stage that occurs before or during system design.

Which Phase is Not Available in Software Life Cycle - Clear Out 

The short answer is that - Abstraction.

Although the global custom software development market is expected to rise at a CAGR of 22.5% (2024-2030), the total revenue forecast of $146.18 billion. Many companies are moving their project into software development and use different types of models to build their software . But why not use abstraction as a model or phases? Abstraction is not listed for several reasons. Let's clarify one by one.

It's a process, not a Phase 

In the first section, we clarify that abstraction is a technique or a process in a lifecycle stage. This process naturally occurs during the other phases of the workflow. If we give an example, it happens in the system design or requirement analysis phase or in the coding period. It is not something that starts and ends in a time-boxed manner. Every stage has some time limit and several stages, such as a specific scope, set of activities, roles, inputs, and outputs.

Basically, designers break the system into high-level components or separate concerns and apply abstraction to manage complexity. When analysts write use-case diagrams, they use this process to abstract user interactions. Developers not only write modular code but also implement abstraction.

These are all manifestations of abstraction, but they occur within other phases, not as a phase on their own. This is why abstraction is classified as an embedded activity, not a standalone SDLC phase.

Cross-Functional And Non-Linear

Another reason abstraction is not in the traditional software development life cycle is its cross-functional and non-linear nature. Because if we see that in every phase, there is a starting and an ending time. Unfortunately, abstraction has no time limit. It weaves through multiple stages of the SDLC and supports various design and implementation tasks. 

There are some stages where abstraction is applied, including architecture, appearance, data and computer separation stages. In the architecture stage, there are many things to do, like presentation, slide, data layer, and logic; all of these are a part of the abstraction time. On the other hand, it also uses Abstracting business entities into structured data models like tables, schemas and objects. 

If we define it as a phase, then the lines between it and other phases would be blurred. Then it led to redundancy or confusion in every project planning and documentation. 

Another reason is that in the Agile or Spiral model, abstraction doesn’t just happen once—it recurs throughout the cycles, influencing each sprint or iteration. All of these reasons make abstraction inappropriate to frame as a one-time phase, like requirement gathering or deployment.

No Trackable Output 

Another reason for this is not a phase is that in every phase, whether it is spiral or v or agile, there every phase a competitive output. Give some examples that will clear it out. The requirements phase gives results such as a software requirements specification. The design phase produces architectural designs, UML diagrams, interface definitions, etc. The testing phase gives us test plans, test cases, and defect reports. The very deployment phase produces a working release or deployment output. 

But in the meantime, if we look, abstraction has no traceable output. So, in that sense, this is not a phase. But it works in every single phase, including:

• The SRS document contains abstract views of business logic.
• The design stage document includes class diagrams that the system works through abstraction.
• API specification abstracts the complexity of internal data flows.

So, while abstraction contributes to deliverables, it is not a deliverable in itself, nor is it traceable in the way other SDLC outputs are. 

Abstraction is a powerful enabler in the software development process, but its nature makes it unsuitable as a separate SDLC phase. 

Inspect of the system is not a phase; it helps teams build better systems, but it to stands alone as a supporting layer. It underpins many SDLC phases, rather than being a visible layer itself. It's a kind of tool that shapes the clarity, modularity, and scalability of software systems across the entire SDLC.

The Role of Abstraction in Different SDLC Models

Apart from that, abstraction has done a lot of inner work that would not be possible without this phase. Let's properly discuss all of that. 

Waterfall  Model 

It is a sequential and linear approach that follows each step. Although waterfall follows upfront planning, designers need to model the system thoroughly before coding begins. So in this model, abstraction plays a considerable role. Logical models are used to abstract real-world business processes into diagrams and specifications. To process all of this, Developers need to think about modules, interfaces, and their interactions, even before implementation starts. So that abstract helps to plan, guiding the rest of the development phases. It will manage a well-structured, detailed plan. 

Agile Model

The Agile model promotes flexibility, iterative development, and collaboration. This project submission model is quite different from others. Instead of delivering the project at once, it divides it into sprints or iterations, each delivering a usable feature or increment. In this model, abstraction plays a continuous and adaptive role. 

As development is ongoing, software developer teams refine and re-abstract requirements into different staff members such as 

• Designs
• Test cases 
• Modular code

The nature of the agile model means that abstraction is constantly revised and revisited according to business requirements. In that sense, this method is highly compatible with the principle of abstractions. 

Spiral Model

This model combines iterative development with risk management. Its focus is on early identification and mitigation of risks by breaking them into simple spirals. Abstraction is used quite often in this model, especially during the risk analysis and engineering phases. The goal of the risk management stage is to break down complex terms or technical challenges into simpler components. 

V-Model 

The V model is the overview of the Validation and Verification model. In this V model, each model contains a specific testing phase. Design systems are broken into abstract components, modules, and interfaces. These abstract components are connected directly with test plans. Close mapping between design and validation it makes the importance V-Model highly structured and reliable. 

Prototype Model

A prototype model is one kind of experimental model that is used before going into the system in a live environment. In this model, abstraction is also helpful for demonstrating functionality and gathering feedback, but not to function as the final product.

Although the five SDLC models differ in structure and methodology, one thing is clear: Abstraction is present in all of them, but not as a staged phase.

Endnote 

As we wrap up our explorations of which phase is not available in software life cycle, it becomes clear that it's essential in both everyday activities and the sophisticated world of software development. Its role is to reduce complexity, promote clarity, and improve design thinking. While it's never recognized as a formal phase in any SDLC model, its importance cannot be denied. Project managers should treat it as a guiding principle that operates across every stage and model of software development.

FAQ

Why Developers Should Still Value Abstraction?

Abstraction is vital to the success of a software development project. Includes :

• Improves reusability
• Increase maintainability
• Facilitates Testing (mocking and stubbing during unit testing)
• Improves Scalability 
• Promotes Team Collaboration

How many phases are in the SDLC?

There are all around has six phases in around, they are as follows

• Requirement gathering and analysis
• Design
• Implementation / Coding
• Testing
• Deployment
• Maintenance

What are the main types of abstraction in software engineering?

There are two types of abstraction at the primary level. Includes :

• Data abstraction 
• Process abstractions