Overview of Fish SDLC Model

The Fish Model is one of the software development approaches in which different teams would work concurrently on every stage of the model's verification (review) and validation (testing). This model's structure is divided into two parallel lines which is just like a fish's skeleton. Fish Model was chosen as the name. It takes a lot of effort and money to run this model. After each phase, Fish Model verification and validation deliver two special reports.

Because, all phases are handled by two separate teams except deployment and maintenance phases.

Phases of Fish SDLC Model

The Fish SDLC model contains 7 phases:

• Requirements Gathering & Planning
• Analysis
• Design
• Development / Coding
• Testing
• Deployment
• Maintenance

1. Planning & Requirements Gathering

a. Planning

The initial and most crucial phase of the SDLC is planning. Senior project participants like the manager, delivery manager, domain experts, sales managers, etc., are involved in this phase.

The model is used to create the system and the project execution strategy which would be chosen by the inputs. Economic and other operational components of a feasibility study are also important.  In this stage, the general planning of the project, planning of resources, and the general execution of the project planning will be completed. Along with this, risk identification is also another main aspect which takes place during this stage. A technical feasibility study will be conducted to assist in identifying and defining the strategy that could be used to implement the project effectively.

b. Requirements Gathering
The most crucial and initial stage of the SDLC is gathering. Business analysts and project managers participate in customer meetings during this phase to collect requirements.

• The client, the product's owner, informs that what should be built, who will use it, and what are its goals.
• The business analyst is the one who collects the client's high-level demands and documents or binds them as business requirements.
• The project leader who is positioned as onshore or offshore will handle the project.

Business Requirement Documents (BRS) are often used to record business needs. It should be noted that the name of the BRS document may change depending on the naming rules established in the project and that names may vary from project to project.

Examples: Business specifications (BS) and customer requirement specifications (CRS).

2. Analysis

After the completion of requirements-acquiring phase, the business needs are translated into technical specifications through which the business analyst (BA) uses the assistance of senior team players, including team leads and SMEs (Subject-matter experts). The SRS (Software Requirement Specification) document contains the technical specifications. 

SRS comprises all the technical specifications for every system involved in the cross application. SRS documentation must be sent to the customer or client-side SMEs for approval before moving on to the next steps.

It should be noted that the SRS document name differs from project to project depending on the naming convention. Examples include Project Specification Documents (PSD), Requirement Specification Documents (RSD), and many more.

3. Design

The Design Document Specification (DDS), created during the design phase, is a design plan based on the SRS specifications. Developers use the SRS requirements to inform their early designs, working prototypes, and descriptions of how the program will function, appear, and flow from window to window. 

Also, the design phase simulates the construction design, user interface, platforms, computer programming, interactions, and security, among other things. As a result, it also describes the functioning of each module. The functioning includes how they connect with various systems and how the system's overall structure is created.

The Specifications for the Design Document, depending on the complexity of its design, which is basically divided into two following groups:

a. High-level Design (HLD): HLD includes high-level modifications to the architecture or design. Senior programmers or architects make HLD.

b. Low-level Design (LLD): Involves highly smooth architectural or design modifications. Senior developers or developers make LLD.

In a Design Document Specification, the architects often offer many approaches. All interested parties were asked to study this DDS before choosing the optimal strategy based on robustness, financial limitations, and deadlines.

When the architecture is chosen, the stakeholders suggest the module designs, data flow diagrams, etc.

4. Development / Coding

The Development phase begins when the DDS is authorized. Developers begin coding by conforming to the organization's coding guidelines. When the coding part is finished, then the programmers apply the programming tools for compilation and debugging the programs to see if the newly written code is functional.

All levels of the development team are involved in this stage. The source code document (SCD) for the code is provided. In this phase, developers are responsible for several tasks, including developing and compiling the source code to ensure it is error-free.

5. Testing

Once the coding has been finished, the code is tested to see if it give results according to the customer and our requirements. Before handing the source code over to the integration team, the developer conducts the testing first, which includes unit testing (UT) and applications integration testing (AIT). The code is moved to a testing domain if everything is in order.  The testing team will then do the testing and performs various tests, including quality testing, system evaluation, acceptance testing, and authorization testing.

The testing team follows the BRS document throughout this phase to ensure whether the new modifications are functioning correctly or not. The testing team raises a bug if anything isn't working correctly, and the development team provides a certain amount of time to resolve it. The testing team carefully checks that each component or module of the project functions according to the STLC (Software Testing Life Cycle) procedure.

Two special testing used in Fish SDLC model are as described below:

Alpha Testing:

This type of testing is carried out to find the possible faults or issues before the product is made available to the public. This testing aims to grab end users interest through white and black box testing. The objective is to go on with an average user's tasks. The internal workers of IT companies work as the tester for alpha testing which would typically take place in a lab environment.

Beta testing:

Real-world consumers of the software product carry it out. It falls under the general category of user acceptance testing. It is considered as the final test which is basically carried out before sending a product to clients. The beta testing process has a lot of direct user input benefits. This type of testing test the product in the customer's environment.

Through consumer validation, beta testing could decrease the chance of product failure and raise product quality. The best example of beta testing is the Google Pay app.

6. Deployment

After the testing phase, the customer reviews the test, the results, and the evidence and gives their clearance for deployment. The current end users of the product could access the new features or function when the software had been put into production.

The design of the system could be complex at the time of deployment if the design is connected with other systems.

7. Maintenance:

Maintenance is the procedure that takes place after the final product. Real-time problems or difficulties may occur when the end user uses the newly deployed software.

If the occured problems are less significant, then the teams can easily handle them and prevent the business from loss.
If the occured problem is critical, then the clients can roll out or roll back for new improvements and refine the required functions.