Interview Questions and Answers

SDLC serves as a guide to the project and provides a flexible and consistent medium to accommodate changes, and perform the project to meet the client's objectives. SDLC phases define key schedules and delivery points that ensure timely and correct delivery to the client within budget and other constraints and project requirements. SDLC co-operates with project control and management activities as they must be introduced within each phase of SDLC. 

SDLC, or Software Development Life Cycle, refers to the process of developing software from initial conception to deployment and maintenance. The SDLC consists of several distinct phases, each with its own set of activities, deliverables, and objectives. The typical phases in the SDLC are as follows:

1. Requirements Gathering: In this phase, stakeholders collaborate to gather and document the software requirements. This involves understanding the needs of users, identifying features, and defining project goals.

2. Analysis: During this phase, the gathered requirements are analyzed in detail. This includes identifying potential challenges, defining scope, and creating prototypes or mockups to visualize the final product.

3. Design: In the design phase, the overall architecture of the software system is developed. This includes designing system architecture, database structure, user interface layout, and defining data flow.

4. Implementation (Coding): In this phase, the actual coding of the software system takes place based on the design specifications. Developers write, test, and debug code to implement the features and functionality defined in earlier stages.

5. Testing: The testing phase involves verifying that the software meets the specified requirements and functions correctly. This includes unit testing, integration testing, system testing, and user acceptance testing to ensure quality and reliability.

6. Deployment: Once the software has been thoroughly tested and approved, it is deployed to the production environment. This involves installing the software on end-user systems or servers and configuring it for use.

7. Maintenance: The maintenance phase involves ongoing support and maintenance of the software. This includes fixing bugs, addressing user feedback, implementing updates and enhancements, and ensuring the continued reliability and performance of the software.

These phases are often depicted as a linear sequence, but in practice, they may overlap or iterate depending on the specific project methodology used (e.g., Waterfall, Agile, Spiral, etc.) and project requirements. Each phase is essential for ensuring the successful development, deployment, and maintenance of software systems.

An SDLC model defines implementation of an approach to the project. It defines the various processes, and phases that would be carried out throughout the project to produce the desired output. There are a variety of SDLC models that exist catering to different needs and characteristics of a project. Some are of iterative nature (Prototyping), whereas some are sequential (waterfall). Some of the well known SDLC models are:

• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• RAD Model
• Agile Model 

• Planning: The first stage of the SDLC is all about determining, what clients want. Project planning is an important component of the software delivery lifecycle because it is here that the team estimates the cost and outlines the new program's needs.
• Gathering Requirements: Defining requirements is part of the planning process to figure out what the application is supposed to perform and what it needs. The development team examines the requirements while keeping the software's design and code in mind.
• Design: The following phase entails distilling all of the software project's requirements, analysis, and design information. This phase is the culmination of the previous two, such as customer feedback and requirement collecting. It is a simulation of how a software application will work. Some particulars of this phase are architecture, platform, security, and user interface.
• Development: This is where the code is really written. Writing code is the first step in putting a design into action. Developers must adhere to the coding requirements set forth by their bosses. Many other jobs are included in the coding process. Many developers need to brush up on their abilities or collaborate with others. It's vital to find and resolve problems and flaws. If any changes or upgrades are needed, the developers can show the work to the business analysts.
• Testing: Before making an application available to users, it's vital to test it. The testing team examines the system's overall functionality. This phase aids in reducing the number of faults and issues seen by consumers. As a result, there is a higher level of user satisfaction and a higher rate of utilization.
• Deployment: Once the product has been thoroughly tested and is ready for deployment, it is made available to customers. The deployment's complexity is determined by the project's size. Many businesses prefer to have the deployment step automated.
• Maintenance: The developed product is looked after throughout this period. The program is updated on a regular basis to keep up with the changing user-end environment or technology. Users find flaws that were not discovered during testing. These issues must be addressed, which may result in new development cycles.

The following are the predominant models that come under SDLC:

    Waterfall model: The waterfall model is a prominent software engineering and product development approach that takes a linear, sequential approach to the software development life cycle (SDLC). The waterfall approach emphasizes a logical step-by-step process. It was the first model in the software business to be extensively adopted. It is divided into phases, with one phase's output becoming the input for the next.
    Agile model: Agile approaches divide jobs into smaller iterations or sections and avoid long-term planning entirely. The scope and requirements of the project are defined at the start of the development phase. The number of iterations, duration, and scope of each iteration are all clearly determined ahead of time. In the Agile process model, each iteration is a small-time "frame" that lasts anywhere from one to four weeks. 
    Iterative model: One of the most straightforward software development life cycle models is the iterative approach. There are several situations when the initial or basic software requirements are well-defined, but the project's complete scope or set of features is unclear. It primarily focuses on preliminary growth and design, then gradually develops momentum as more complex needs are met until the final software is completely constructed. 
    Spiral model: The spiral model is a risk management strategy that combines the iterative development process model with parts of the Waterfall approach. The spiral approach is preferred by software engineers for large, expensive, and complex projects.
    V-model model: The V-model is an SDLC paradigm in which processes are executed in a V-shape in a sequential manner. The Verification and Validation model is another name for it. The waterfall model is extended by the V-Model. Every phase of the development cycle has a testing phase that is directly linked to it. 

RAD involves iterative development along with the creation of prototypes. It uses interactive use of techniques and prototypes to define user requirements and system design clearly. Structured techniques are used to create initial design models based on user input and prototypes are built on top of that. The end users and analysts use the prototypes to validate and enhance the requirements and design models. The process lasts till a set of final technical requirements and design models have been created. 

Waterfall is a sequential and non-iterative SDLC model which describes the flowing of phases downwards one by one. The process does not start a phase unless the previous phase is completed once and for all completely. The waterfall model consists of the following phases:

• • Requirements gathering
  • Design
  • Implementation
  • Testing
  • Maintenance 

• Requirements gathering: All the requirements are gathered and analysis is performed for the complete system.
• Design: Various design models are created for the complete system after the requirements gathering phase has been completed and ended.
• Implementation: The complete system is implemented once the design for the system has been frozen.
• Testing: The complete system is tested after all the construction and integration has completed.
• Maintenance: Post implementation support carries out after the implementation of the system. 

The strengths of the waterfall model are:

• No planning needed
• Works well for small projects with fixed and clear requirements.
• Lesser cost as planning overhead is less
• Quickest delivery of the complete system 

Phases of the incremental model are the same as waterfall i.e. Requirements, design, implementation, testing, and maintenance.

However, instead of following the waterfall once and for all linearly, the incremental model takes a different approach. These phases are repeated incrementally as business value is delivered incrementally as well.

For every single phase and increment a waterfall model is followed. The waterfall model is then put in a cycle of increments along with verification of requirements, and design. 

Phases in spiral model:

a) System requirements are identified in detail.
b) An initial design is created for the new system based on the requirements in previous phase. All feasible and technical approaches are identified and analyzed to build the system. The design is done on a very broader and deeper scope to identify and deal with potential risks in the system.
c) A prototype is created depicting a few features of the system.
d) A second prototype is created using 4 steps: Evaluate first prototype, define requirements for second prototype, planning and designing for second prototype, constructing and testing second prototype.

There is no specific SDLC model that can be used for all types of projects and situations. If none of the popular SDLC models suit a specific project then, pick the closest matching SDLC model and modify it as per needs. Identify how important is risk assessment and use spiral's risk assessment methodology if it's a risk-critical project.

The project should be delivered in small chunks, ideally merging the incremental model with the V-shaped model. One must spend ample time choosing the right model or customizing one to suit a project for its successful and efficient completion. 

LLD (Low-LevelLevel Design) is a term that refers to the process of detailing. It provides a full description of each module, including actual logic for each system component and a thorough examination of each module's specifications. Every program undergoes logic design, which is subsequently recorded as program specifications. A unit test plan is prepared for each software. The micro-level or intricate design is another name for it. After the High-Level Design, the Low-Level Design is created.

• It is not a useful method for small development projects.
• It requires an expert to take important decisions in the meeting.
• The cost of implementing an agile method is a little more compared to other development methodologies.
• The project can easily go off track if the project manager is not clear about what outcome he/she wants.

Weaknesses of waterfall model are:

a) It is Inflexible
b) Accommodating changes is very hard
c) Longest tangible delivery time. The customer does not see anything but the whole product when it�s ready.
d) Unsuitable for large projects and where requirements are not clear. 

• Requirements are very clear and fixed.
• There are no ambiguous requirements.
• Ample resources with required expertise are available freely.
• The client has high confidence in the organization.
• The organization has experience of similar projects.
• The project is short.

The V-shaped SDLC model is an extension of the waterfall model.

The typical waterfall moves linearly downwards, whereas, in the V-shaped model, phases are turned upwards after the coding phase to form the V shape. It demonstrates the relationship between each phase of SDLC and its respective testing phase. Unlike the waterfall model, the V-Shape includes early test planning.

Phases in V-Shaped model:
Verification phases are on the left side of the V-shape. It consists of:

Requirements analysis: Requirements are gathered and analysis is performed to understand the problem and propose a solution.
System Design: Engineers analyze the requirements gathered and propose ways the system can be created or built from a feasibility point of view.
Architecture design: Architecture of the system is designed consisting of various modules, depicting their relationships and communication between them. 
Module design: This is a low level design where modules are designed individually and in a detailed manner.

Coding: This is at the bottom of the V-Shape model. Module design is converted into code by developers.

Validation phases are on the right side of the V-shape. It consists of:
Unit testing: Testing by analysis of the code by developers for their independent modules is done.
Integration testing: Independent modules are tested together to validate interface and expose errors in them.
System testing: The system is tested against the system specifications.
User Acceptance testing: Testing is performed by end users to validate that the requirements mentioned in requirements phase have been met by the system or not before accepting it for production. 

Strengths of V-Shaped model:

a) Simple and easy to use model.
b) Every phase has clear and fixed deliverables.
c) Higher chances of success as test planning starts early in the SDLC cycle.
d) Quickest for project where requirements are fixed and clearly defined. 

Strengths of the prototype model are:

a) Gains customer's confidence as developers and customers are in sync with each other's expectations continuously.
b) Ideal for online systems where high level of human computer interaction is involved.
c) Very flexible, as changes in requirements can be accommodated much more easily with every new review and refining.
d) Helps the developers and users both understand the system better.
e) Software built through prototyping needs minimal user training as users get trained using the prototypes on their own from the very beginning of the project.
f) Integration requirements are very well understood and deployment channels are decided at a very early stage. 

Weaknesses of the Prototype model are:

a) Focusing on the prototype can mislead developers from understanding the actual desired system.
b) End users get confused, believing the prototype to be the complete system
c) Developers might misunderstand end users objectives.
d) Developer might get too involved in prototype and deviate from the actual system that the prototype must be converted into.
e) Expensive as prototypes need a lot of effort and time. It may take a lot of work to be done for very less needed work to be achieved.

Phases in RAD:

• Business modeling: The information flow is identified between various business functions.
• Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business.
• Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. The description is identified and created for CRUD of data objects.
• Application generation: Automated tools are used to convert process models into code and the actual system.
• Testing and turnover: Test new components and all the interfaces. 

Strengths of RAD:

a) Reduced development time.
b) Increases reusability of components
c) High modularization achieves a more flexible and maintainable system
d) Quick initial reviews occur.

e) Encourages customer feedback
f) Integration from very beginning solves a lot of integration issues.
g) Business owners actively participate 

Weaknesses of RAD:

a) Depends on strong team and individual performances for identifying business requirements.
b) Only system that can be modularized can be built using RAD
c) Requires highly skilled developers/designers.
d) High dependency on modeling skills
e) Inapplicable to cheaper projects as cost of modeling and automated code generation is very high for cheaper budgeted projects to befit. 

RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time. It should be used if there's high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months). 

The strengths of the incremental model are:

a) Develop high-risk business features first
b) Every increment delivers an operational product
c) Customer's confidence is high as they validate every increment and provide feedback
d) Low initial delivery cost
e) Changes in requirements can be accommodated easily.
f) More flexible than waterfall. 

The incremental model should only be used when:

• The requirements of the complete system are clearly defined and understood.
• Major requirements must be defined; however, some details can evolve with time.
• There is a need to get a product to the market early.
• New technology is being used
• Resources with needed skill sets are not available
• There are some high-risk features and goals. 

Strengths of the Spiral model:

a) Early identification of potential risk areas.
b) Customer sees a prototype very early in the SDLC.
c) Critical and risky features are built first for risk mitigation and clarifying requirements.
d) Design can evolve with iterations.
e) Feedback from users helps maintain their expectations.
f) Cost is assessed frequently, hence better planning. 

Spiral model should be used when:

a) Prototypes are expected/needed.
b) Large and high budget projects
c) When risk assessment is very critical
d) Requirements are not very clearly defined.
e) Requirements are vague and even complex
f) The organization does not have much experience with the domain.
g) Ample time is available. 

Choosing or building the right team is vital for the success of any project.

A project needs a variety of skills and qualities that are not present in any individual. However, as a workaround, a team should be built of people with a variety of skill sets to fulfill the project need.

The main advantage of choosing team members with a mix of personality types is that it provides a wider range of views towards a project or any specific action item in the project, e.g. requirements, design, development, testing or even implementation. Different views allow for a broader angle to a problem and solution minimizing the risk of missing requirements or misunderstanding them.

Some of the personality traits that are essential to any project are:

• Aggressive go getter, contrary, a calm patient and more laid back personality
• Risk taker, contrary, a cautious personality
• Strategic, contrary, analytical personality
• Lateral thinking

Different situations in a project are handled better by different personality types and hence a perfect blend/mix of personality types is essential for the project to complete successfully. 

The 4 stages of team building are:

Forming: Team members are told what is expected out of them and where do they fit in the team. The team is guided using operating guidelines, and communication within.

Storming: During this phase team members show some resistance and frustrations trying to work together. There would be jealousies and ego clashes and the team manager must act as a referee or a coach.

Norming: In this phase the team has learnt to function as a whole. Team members find their consistent ways of working and hold their ideas back to avoid problems and conflicts. The team manager guides the team to not hold themselves back by increasing responsibilities and pressures.

Performing: In this phase the team has learnt to perform their role as whole, have and resolve conflicts, take risks, make adjustments or compromises, and perform actively to face various challenges. 

Of course. There are no hard and fast requirements for a developer to implement any SDLC model for developing a software project. The ability to simplify a project into modules and ascertain the correct progression for completion is the only reason for which SDLC models and methodology was designed in the first place. You can surely work without them but the challenges will be more and there won't be any specific process to organize your work as a whole.

The Rapid Application Development (RAD) paradigm is a software development method that relies on prototyping rather than detailed design. It should be utilized when a system that can be modularized in two to three months is required. It should be employed if there is a large number of designers available for modeling and the budget allows for their costs as well as the costs of automated code generation technologies.