Software Development Life cycle(SDLC)

Software Development Lifecycle:

Software Development Lifecycle (SDLC) Refers to Processes used to plan, create, test and deploy an information system.  It consist a detail plan how a system is going to develop, how to maintain and replace specific software.

SDLC metrology helps to improve software development quality and overall development.

Basically it consists 6 steps:

  1. Gather Requirement
  2. Design
  3. Development
  4. Testing
  5. Deploy
  6. Maintenance

 

  1. Requirement Gathering: Understand the user requirements and user business goals.
  2. Design:  Design the software UI and back-end Structures i.e database.
  3. Development: In development phase, developer do the coding on selected  development platform.
  4. Testing:  Once development activity has finished, testing activity takes place. In this phase tester verify the system functionality against the requirement.
  5. Deployment: Given to the users in a production and utilize the system.
  6. Maintenance:  Bug Fixes and other updates needed in the system.

Following figure will help you to understand the SDLC process flow.

SDLC Model – Waterfall

Waterfall Model:

It’s a traditional software development life cycle model. In this model you can see progress as following downward like a waterfall, through different phases like requirement gathering and analysis, design, coding, testing and maintenance.

In this model only next phase begun when the goal of previous phase has been completed.

Advantages of Waterfall:

  • Requirements do not change frequently, so we get a stable product.
  • Very simple to implement
  • Significant project progress visibility to manager as well as client.
  • A perfect model for a big project.

Disadvantages of Waterfall:

  • Reverse engineering is not possible i.e we cannot go back and change requirement once design has been developed.
  • Requirement changes on later stage are difficult to incorporate.
  • Customer may not be satisfied, if the changes they required are not incorporated in the product.
  • It is not suitable for long term projects where requirements may change time to time
  • Waterfall model can be used only when the requirements are very well known and fixed

Waterfall model process flow:

Water Fall Model of SDLC

SDLC Model – Prototyping Model

Prototyping Model –

Prototyping is defined as the process of developing a working replication of a product or system i.e a dummy product or system that has to be developed. It’s not the actual product but give the customer a fair idea what product is going to develop.

This model is very popular software development life cycle model. This model is used when the customer do not know the exact project requirement in beginning. A prototype of the end product is first developed, tested and refined as per customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis for developing the final product.

In this method customer has advantages to see their product in early phases and if they want any changes they can do the same.

There are two approaches for this model:

Rapid/ Throwaway prototyping –

Through this technique team is getting an idea about system through customer feedback. In this method it’s not necessary that initial prototype will be the final accepted prototype. Continuous customer feedback help to prevent unnecessary design faults and hence, the final prototype developed is of a better quality.

Evolutionary Prototyping –

Evolutionary prototyping also called as breadboard prototyping. In this method, the prototype developed initially is incrementally refined on the basis of customer feedback till it finally gets accepted. In comparison to rapid/throwaway prototyping, it’s a batter approach because this method saves lots of time and efforts. This is because developing a prototype from scratch for every iteration can be very frustrating for the developers and manager.

Following figure shows process flow of Prototype model.

 

Advantages of prototype model –

  • Customer satisfaction, because customer can see their product dummy at early stage.
  • At early stage missing functionality can be identified.
  • Requirement can be change at early stage.
  • Developer and tester can re-use the developed prototype.

Disadvantages of prototype model –

  • It’s a time consuming model if customer continuously ask for changes.
  • Customer may get confused in the prototypes and real systems.
  • There is no parallel deliverable.
  • Poor Documentation due to continuously changing customer requirements.
  • The customer might lose interest in the product if he/she is not satisfied with the initial prototype.

 

 

SDLC Model – Agile

SDLC Model – Agile

These days Agile is a very popular SDLC model. Agile methodology is a practice that supports continuous iteration of development. It’s a combination of iterative and incremental approach which focuses on process adaptability and customer satisfaction.

In agile, whole project breaks in to the small incremental builds. Every iteration typically takes 1 to 3 weak times. After every development iteration, the customer is able to see the result and understand if he is satisfied with it or not. Scrum approach is one of the popular approaches used in agile model.

To know more about agile scrum click here

Advantages of Agile –

  • Less Documentation.
  • Change adaptability, even at the last stage of build.
  • Batter customer engagement.
  • Fast development process
  • Agile promote team work and cross training.
  • Concurrent development and delivery within define time frame work gives agile an extra edge.
  • Agile project is easy to manage.

Disadvantages of Agile –

  • Not much compatible for large and complex project
  • Customer heavily interaction required, so if customer is not clear about their product they can mislead the agile team.
  • Transfer of technology to new team members may be quite challenging due to lack of documentation.
  • Each individual in agile team should be self-motivated and self-driven. If these things missing in team member, it can cause problem for project.

SDLC Model – Agile

Agile Methodology –

These days Agile is a very popular SDLC model. Agile methodology is a practice that supports continuous iteration of development. It’s a combination of iterative and incremental approach which focuses on process adaptability and customer satisfaction.

In agile, whole project breaks in to the small incremental builds. Every iteration typically takes 1 to 3 weak times. After every development iteration, the customer is able to see the result and understand if he is satisfied with it or he is not. Scrum approach is one of the popular approaches used in agile model.

Advantages of Agile –

  • Less Documentation.
  • Change adaptability, even at the last stage of build.
  • Batter customer engagement.
  • Fast development process
  • Agile promote team work and cross training.
  • Concurrent development and delivery within define time frame work gives agile an extra edge.
  • Agile project is easy to manage.

Disadvantages of Agile –

  • Not much compatible for large and complex project
  • Customer heavily interaction required, so if customer is not clear about their product they can mislead the agile team.
  • Transfer of technology to new team members may be quite challenging due to lack of documentation.
  • Each individual in agile team should be self-motivated and self-driven. If these things missing in team member, it can cause problem for project.

BRS VS SRS VS FRS

BRS: Business Requirement Specification –

It is a high level document which include all requirement demanded by client. Basically it includes all requirements which should be the part of proposed system.

BRS says, proposed system supposed to include this requirement as functionality.

Business Analyst prepare this document.

To Know more about BRS template Click Here 

SRS: System Requirement Specification –

SRS describes the entire system flow, overall functionality of the system, how the data will flow within the system. It describes each module functionality.

SRS also include use cases that explain user interaction with the system or software. It also describes non- functional requirements like security, availability etc.

This document is developed by System Analyst but in small organisation BA also prepare SRS.

To Know more about SRS template Click Here

FRS – Functional Requirement Specification –

There is a very minor difference between FRS and BRS. FRS converted into functionality and says that how this requirement is going to work as a part of proposed system. FRS also explains sequence of operations to be followed on every single process.

This document is developed by developers and solution architect.

Now I am going to summaries it in tabular form

BRS

SRS

FRS

BRS stands for Business requirement specification. SRS stand for software requirement specification. FRS stand for functional requirement specification.
BRS does not include use case generally. SRS include use case to describe user interaction with system. In this use case are not included.
In BRS , we define what exactly customer wants. In SRS we describe all the business functionality of the application. In FRS, we describe the particular functionalities of   every single page in detail from start to end.
BRS explain story of whole requirements. SRS explain all functional and non- functional requirement. FRS explains the sequence of operation process on each and every stage.
SRS is a complete document which describe complete system behavior. It describe the all functionality of the system which would be efficient for end user. IT describe the business requirements in detail level.

 

Use Case

What is use case?

Use case a technique which use in requirement analysis. Simply it describes how a user uses a system to accomplish particular goal.

It’s a step of a particular use of the system by an actor or user.

Purpose of use case diagram

  • Define goal of the system
  • Define user interaction steps with the system.
  • System architecture validation
  • Easy to understand by end user and developer.

How do you write a Use Case?

Use case contains the following elements:

  1. Name – A clear verb/Noun/actor which describe the overall use case.
  2. Brief Description – A brief paragraph that describing the scope of use cases.
  3. Actors – A list of all types of users, who will use the system. Actor names should not correspond to job titles. Actor can be primary and secondary.
  4. Preconditions – List of conditions that need to be true when the use case begin.
  5. Basic Flow – It’s a set of steps that user need to take for successfully accomplish thegoal of use cases. A clear description what the system does in response to each user action.
  6. Alternate Flows – Capture the less common users, whose interaction with the system will very less.Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example:  X.Y.AC.1.
  1. Post Conditions – Anything that must be true when the use case is complete.