• Software Development Life Cycle (SDLC) is a set of phases that provide a common understanding of the software building process.
• How the software is realized and developed from the business understanding and requirements elicitation phase to convert these business ideas and requirements into functions and features until its usage and operation to achieve the business needs.
• Generally a software engineer should have enough knowledge on how to select the SDLC model based on the project context and the business requirements.
• Therefore, it may be required to choose the right SDLC model according to the specific concerns and requirements of the project to ensure its success.
• You can think of SDLC models as tools that you can use to better deliver your software project. Therefore, knowing and understanding each model and when to use it, the advantages and disadvantages of each one are important to know which one is suitable for the project context.

• There are some various software development life cycle models defined and designed which are followed during the software development process. These models are also referred as Software Development Process Models”.
• Each process model based on a Series of rules unique to its type to ensure success in the process of software development.

• Following are the most important and popular SDLC models followed in the industry & miuns

• • Waterfall Model
  • Iterative Model
  • Spiral Model
  • V-Model
  • Big Bang Model

• The waterfall is a widely accepted SDLC model. In this approach, the whole process of the software development is divided into various phases. In this SDLC model, the outcome of one phase acts as the input for the next phase.
• This SDLC model is documentation-intensive, with earlier phases documenting what need be performed in the subsequent phases.

• The incremental model is not a separate model. It is essentially a series of waterfall cycles.
• The requirements are divided into groups at the start of the project. For each group, the SDLC model is followed to develop software.
• The SDLC process is repeated, with each release adding more functionality until all requirements are met. In this method, every cycle act as the maintenance phase for the previous software release.
• Modification to the incremental model allows development cycles to overlap. After that subsequent cycle may begin before the previous cycle is complete.

• In this type of SDLC model testing and the development, the phase is planned in parallel.
• So, there are verification phases on the side and the validation phase on the other side. V-Model joins by Coding phase.

• Agile methodology is a practice which promotes continue interaction of development and testing during the SDLC process of any project.
• In the Agile method, the entire project is divided into small incremental builds. All of these builds are provided in iterations, and each iteration lasts from one to three weeks.

• Phase 1: Requirement collection and analysis
• Phase 2: Feasibility study
• Phase 3: Design
• Phase 4: Coding
• Phase 5: Testing
• Phase 6: Installation/Deployment
• Phase 7: Maintenance

• The requirement is the first stage in the SDLC process. It is conducted by the senior team members with inputs from all the stakeholders and domain experts in the industry.
• Planning for the quality assurance requirements and recognization of the risks involved is also done at this stage.

• Once the requirement analysis phase is completed the next step is to define and document software needs.
• This process conducted with the help of ‘Software Requirement Specification’ document also known as ‘SRS’ document.

• Economic: Can we complete the project within the budget or not ?
• Legal: Can we handle this project as cyber law and other regulatory framework/compliances.
• Operation feasibility: Can we create operations which is expected by the client ?
• Technical: Need to check whether the current computer system can support the software
• Schedule: Decide that the project can be completed within the given schedule or not.

• In this third phase, the system and software design documents are prepared as per the requirement specification document. This helps define overall system architecture.
• This design phase serves as input for the next phase of the model.There are two kinds of design documents developed in this phase,

• Brief description and name of each module
• An outline about the functionality of every module
• Interface relationship and dependencies between modules
• Database tables identified along with their key elements
• Complete architecture diagrams along with technology details

• Functional logic of the modules
• Database tables, which include type and size
• Complete detail of the interface
• Addresses all types of dependency issues
• Listing of error messages
• Complete input and outputs for every module

• Once the system design phase is over, the next phase is coding. In this phase, developers start build the entire system by writing code using the chosen programming language.
• In the coding phase, tasks are divided into units or modules and assigned to the various developers. It is the longest phase of the Software Development Life Cycle process.
• In this phase, Developer needs to follow certain predefined coding guidelines. They also need to use programming tools like compiler, interpreters, debugger to generate and implement the code.

• Once the software is complete, and it is deployed in the testing environment. The testing team starts testing the functionality of the entire system.
• This is done to verify that the entire application works according to the customer requirement.

• Once the software testing phase is over and no bugs or errors left in the system then the final deployment process starts.
• Based on the feedback given by the project manager, the final software is released and checked for deployment issues if any.

• Bug fixing – bugs are reported because of some scenarios which are not tested at all
• Upgrade – Upgrading the application to the newer versions of the Software
• Enhancement – Adding some new features into the existing software

• Agile testing refers to a software testing practice that follows different principles of agile software development.
• In other words, agile testing means testing software for defects or any other issues quickly or within the context of agile and give quick feedback for better and faster development of the project.

• Testing and development run parallel in agile testing. The tester’s role lies not in identifying defects in the application but in behaving as a developer and bringing in improvements, suggestions, and test cases to be included in the application.
• In agile testing, testers follow the entire lifecycle but due to constant feedback and regular interaction between developers and customers, the application can be delivered in a short time without compromising on the quality.
• The tester and developers respond to quick changes in the application rather than following a fixed plan.

• The principles of agile testing are:

• • Testing is NOT a phase,
  • Everyone participates in the testing process,
  • It shortens the response time of feedback,
  • Reduces test documentation.

• Agile testing requires continuous interaction between developers, customers, managers, stakeholders, and testers.
• Testing is an important component of each phase of the developmental process.

• Unlike the waterfall model, in an agile model, a test plan is written and updated for every release.
• The agile test plan includes types of testing done in that iteration like test data requirements, infrastructure, test environments, and test results.
• Typical test plans in agile includes

• • Testing Scope,
  • New functionalities which are being tested,
  • Level or Types of testing based on the features complexity,
  • Load and Performance Testing,
  • Infrastructure Consideration,
  • Mitigation or Risks Plan,
  • Resourcing,
  • Deliverables and Milestones.

• Agile testing life cycle spans through four stages.

• Software Testing Life Cycle (STLC) is the testing process which is executed in systematic and planned manner.
• In STLC process, different activities are carried out to improve the quality of the product.

• Requirement Analysis
• Test Planning
• Test Case Development
• Environment Setup
• Test Execution
• Test Cycle Closure

• Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). In this step Quality Assurance (QA) team understands the requirement in terms of what we will testing & figure out the testable requirements.
• If any conflict, missing or not understood any requirement, then QA team follow up with the various stakeholders like Business Analyst, System Architecture, Client, Technical Manager/Lead etc., to better understand the detail knowledge of requirement.

• Test Planning is most important phase of Software testing life cycle where all testing strategy is defined.
• This phase also called as Test Strategy phase. In this phase typically Test Manager (or Test Lead based on company to company) involved to determine the effort and cost estimates for entire project.

• The test case development activity is started once the test planning activity is finished.
• This is the phase of STLC where testing team write down the detailed test cases. Along with test cases testing team also prepare the test data if any required for testing.
• Once the test cases are ready then these test cases are reviewed by peer members or QA lead.

• Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested.
• This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it.

• Once the preparation of Test Case Development and Test Environment setup is completed then test execution phase can be kicked off.
• In this phase testing team start executing test cases based on prepared test planning & prepared test cases in the prior step.

• Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives and Software.
• Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process.

• Given an array of integers, our task is to write a program that efficiently finds the second largest element present in the array.

• Initialize two variables first and second to INT_MIN as,
  • first = second = INT_MIN

• • Start traversing the array,

a) If the current element in array say arr[i] is greater than first. Then update first and second as,

• • second = first
  • first = arr[i]

b) If the current element is in between first and second, then update second to store the value of current variable as
• • second = arr[i]

• Return the value stored in second.

• Iterate the given array.

• If current array value is greater than largest value then move the largest value to secondLargest and make current value as largest

• If the current value is smaller than largest and greater than secondLargest then the current value becomes secondLargest.

To find easy to way of Divisibility by 11,

• The multiples of 11: 22, 33, 44, 55, etc. But we did’t easy to find the number 2728, 54695 is divisible by 11.
• Here an easy way to test for divisibility by 11. Take the alternating sum of the digits in the number, read from left to right. If that is divisible by 11, so is the original number.
• So, for example, 2728 has alternating sum of digits 2-7+2-8 = -11. Since -11 is divisible by 11, so is 2728.
• Similarly, for 54695, the alternating sum of digits is 5-4+6-9+5 = 3. This is not divisible by 11, so neither is 54695.

n = 122164154695
Queries: l = 0 r = 3, l = 1 r = 2, l = 5 r = 9, l = 0 r = 11

True
True
False
True

#include  
using namespace std; 
  
const int MAX = 1000005; 
  
// To store sums of even and odd digits 
struct OddEvenSums 
{ 
    int e_sum; // Sum of even placed digits 
  
    int o_sum; // Sum of odd placed digits 
}; 
  
OddEvenSums sum[MAX]; // Auxiliary array 
  
// Utility function to evaluate a character's 
// integer value 
int toInt(char x) 
{ 
    return int(x) - 48; 
} 
  
// This function receives the string representation 
// of the number and precomputes the sum array 
void preCompute(string x) 
{  
    sum[0].e_sum = sum[0].o_sum = 0; // Initialize everb 
  
    // Add the respective digits depending on whether 
    // they're even indexed or odd indexed 
    for (int i=0; i    { 
        if (i%2==0) 
        { 
            sum[i+1].e_sum = sum[i].e_sum+toInt(x[i]); 
            sum[i+1].o_sum = sum[i].o_sum; 
        } 
        else
        { 
            sum[i+1].o_sum = sum[i].o_sum+toInt(x[i]); 
            sum[i+1].e_sum = sum[i].e_sum; 
        } 
    } 
} 
  
// This function receives l and r representing 
// the indices and prints the required output 
bool query(int l,int r) 
{ 
    int diff = (sum[r+1].e_sum - sum[r+1].o_sum) - (sum[l].e_sum - sum[l].o_sum); 
  
    return (diff%11==0); 
} 
  
//driver function to check the program 
int main() 
{ 
    string s = "122164154695"; 
  
    preCompute(s); 
  
    cout << query(0, 3) << endl; 
    cout << query(1, 2) << endl; 
    cout << query(5, 9) << endl; 
    cout << query(0, 11) << endl; 
  
    return 0; 
} 

1 
1
0
1

• MVP is a design pattern for developers to write their code in a more readable, maintainable, and scalable manner.
• In MVP, our code is divided into three parts named Model, View, and Presenter rather than placing the whole code in one activity.
  • Model – The model handles the data part of our application.
  • Presenter – It acts as a bridge that connects a Model and a View.
  • View – This is responsible for laying out views with the relevant data as instructed by the Presenter.

• Everything which is related with data is a part of the Model. The Model contains a data provider and the code which fetches and updates the data.
• This part of MVP updates the database or communicates with a web server.

• The Presenter contains the application’s business logic and when an operation is performed or data is changed then it will notify the View that it needs to update.

• The View part of MVP contains the visual parts of our application, like showing messages, and also handles visibility.
• View contains only that part of the code which is related to UI and it does not contain any logic related to the displayed data. The View is controlled by the Presenter.

• The diagram below depicts a basic MVP structure.

• Activity, Fragment and a CustomView act as the View part of the application.
• The Presenter is responsible for listening to user interactions (on the View) and model updates (database, APIs) as well as updating the Model and the View.
• Generally, a View and Presenter are in a one to one relationship. One Presenter class manages one View at a time.
• Interfaces need to be defined and implemented to communicate between View-Presenter and Presenter-Model.
• The Presenter is responsible for handling all the background tasks. Android SDK classes must be avoided in the presenter classes.
• The View and Model classes can’t have a reference of one another.