SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

1. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Consult America Technology Consulting Services

2. 1. Software Development Life Cycle(SDLC) 2. Software development methodologies 3. Scrum 4. All About Testing 5. Software Testing Life Cycle(STLC)

3. 1. SOFTWARE DEVELOPMENT LIFE CYCLE SDLC : Software Development Life Cycle SDLC is the acronym of Software Development Life Cycle. It is also called as Software development process. The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process.

4. 1. SOFTWARE DEVELOPMENT LIFECYCLE Software Development is the process of developing software through successive phases in an orderly way. This process includes the following phases: • The writing of programming code • The preparation of requirements/objectives • The design of the software • Confirmation that what is developed has met the requirements/objectives • Releasing the finished software to the customer (client) • Planning • Providing support to the customer after releasing the finished software

5. System Development Life Cycle

6. 1. SOFTWARE DEVELOPMENT LIFECYCLE What exactly do Software Testers do? • Our job is to test the application against the requirements • Requirement: Valid users are able to login • Test: Login • Step 1: Launch the application (www.piit.us) • Expected Result: The application is launched and available • Step 2: Enter a valid user id (testuser1) • Expected Result: Valid user id is entered • Step 3: Enter a valid password (abcd1234) • Expected Result: Valid password is entered • Step 4: Click on Sign in button • Expected Result: _________________ • Each step will have an expected result • When a test is executed (tester performs the steps on the application) the actual results are recorded. • When the Actual Results do not match the Expected Results  Bug or Defect

7. 1. SOFTWARE DEVELOPMENT LIFECYCLE People Involved : • Developers: Write the programming code (Java, C++, PHP, etc.) • Business Analysts: Gather and Create Requirements. • QA Testers: Verify that the software meets the requirements . • Project Manager: Manages the overall Project to ensure it stays within budget and on time

8. 1. SOFTWARE DEVELOPMENT LIFECYCLE SDLC Phases is Planning, Analysis, Design, Development, Testing, Deployment (Production and Maintenance Phase) Phase.

9. 1. SOFTWARE DEVELOPMENT LIFECYCLE Planning Phase: • Planning is the most important and fundamental phase in the SDLC • People Involved: • Senior members of the Development Team (PMs, Sr. BAs, Sr. Dev, Sr. Testers and/or Test Lead/Test Manager) • Client Requirement Analysis Phase : • Main Contributor: Business Analysts (Translate Requirements) • BAs gather the Business Requirements from the client (the business side) • BAs then convert the Business Requirements into Technical Requirements which will be used by the development and testing teams (the technical side) • BAs are the Subject Matter Experts (SMEs) for the requirements

10. 1. SOFTWARE DEVELOPMENT LIFECYCLE Design Phase : • BA will meet the client – gather the business requirements • BA then defines and documents the business requirements and gets final approval from the client • Once the client approves the BAs work, the Business Analyst creates a document with the formalized Business Requirements (BRD) • Then the BRD is approved by the Project Manager • After approval from Project Manager (PM), the Business Analyst begins the task of converting the business requirements to technical requirements (SRS) • Documentation: • BRD – Business Requirement Document • BA documents all requirements specified by the client • Business Requirements • SRS – Software Requirement Specifications • Consists of all the product requirements to be designed and developed during the project’s life cycle • Technical Requirements

11. 1. SOFTWARE DEVELOPMENT LIFECYCLE Development Phase : • Actual development of the software product begins and the product is built • Developers use the Technical Requirements found in the SRSAND the Design Documents (DDS) as a guide to know what and how to develop the application • Programming Code (Java, C, C++, C#, PHP, etc.) is generated according to the technical requirements • Developers must follow coding guidelines defined by their organization and the programming languages/tools they’re using • Examples: • Java is a case-sensitive language  The application must be developed with this restriction in mind • The organization wants all classes to follow a set naming convention (increases standardization) • Programming language is chosen based on the needs of the software being developed

12. 1. SOFTWARE DEVELOPMENT LIFECYCLE QA/Testing Phase : • Main Contributors: QA Testing Team • Once the programming code is developed by the developers, the application is tested against the requirements • Testing Against Requirements: • Ensures that the product is actually solving the needs addressed and gathered during the Requirement Analysis Phase • If the client requested that only customers who have paid can access the application, then we design a test case that will verify that only paid customers can access the application • Testers design test cases (containing test steps) and link them to the requirements to prove to the client that the requirements they asked for have been met (Requirement Traceability Matrix) • All types of testing are done during this phase

13. 1. Software Development LifecycleQA/Testing Phase -Types of Testing:Functional Testing: Determines if the application is working (functioning)Non-Functional Testing: Determines how efficiently the application is working

14. 1. SOFTWARE DEVELOPMENT LIFECYCLE Production/Implementation Phase : • Also Known As: Deployment Phase • After the application has been successfully tested (and all issues have been resolved) the product is delivered to the client • As soon as the product is deployed to the customer, they will first do beta testing • If any changes are required or if any bugs are found, the client will report them to the development team • After the changes are made and the bugs are fixed, the final deployment will happen

15. 1. SOFTWARE DEVELOPMENT LIFECYCLE Maintenance Phase : • Once the client starts using the finished application, they may encounter problems or issues that slipped past the Testing team • Additionally, finished applications need to be updated from time to time • To deal with these situations, the development team (BAs, Developers, & Testers) work to maintain the finished application • When issues are found, the client’s help desk organization will verify that it’s an issue • If the help desk determines the issue to be valid, they will pass it on to the QA Team to further analyze the issue and verify that it is indeed a bug. • In this situation, the QA Team will log a defect and report it to the Developers to fix • The Developers will fix the bug, and a new build (version) will be released to the client after the QA Team tests the new build

16. 2. Software Development methodologies • Development Methodologies are the various processes which can be selected for the development of the project depending on the project’s goals • The selection of a specific methodology has a very high impact on the testing that is carried out • It will define the what, where, and when of our testing • It will influence various types of testing • Selection of a specific methodology will also help us determine which testing techniques to use • Development and Testing are carried out in various ways depending on the methodology chosen

17. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Development methodologies • Waterfall Methodology • V-Model • Incremental Methodology • RAD Methodology • Agile Methodology • Iterative Methodology • Spiral Methodology • Prototype Methodology

18. 2. SOFTWARE DEVELOPMENT METHODOLOGIESWATERFALL METHODOLOGY

19. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • Each phase of the SDLC must be completed before the next phase can begin • Waterfall is good for these types of project: • Small projects • Projects where all requirements are known and are not likely to change • At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project • SDLC phases do not overlap each other • Testing starts after development has been completed

20. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Advantages of waterfall: • This model is simple and easy to understand and use. • It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. • In this model phases are processed and completed one at a time. Phases do not overlap. • Waterfall model works well for smaller projects where requirements are very well understood Disadvantages of waterfall: • Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. • No working software is produced until late during the life cycle. • High amounts of risk and uncertainty. • Not a good model for complex and object-oriented projects. • Poor model for long and ongoing projects. • Not suitable for the projects where requirements are at a moderate to high risk of changing.

21. 2. SOFTWARE DEVELOPMENT METHODOLOGIESV-MODEL

22. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • Requirements (BRD & SRS) begin the V-model lifecycle (similar to Waterfall) • HOWEVER a System Test Plan is generated PRIOR to Development • This test plan focuses on meeting the functionality specified in the requirements • High-Level Design Phase – focuses on system architecture and design • Provides an overview of the solution, platform, system, product, and processes • An Integration Test Plan is generated in this phase in order to test how the different pieces of the application will work once put together • Low-Level Design Phase – Actual software components are designed • Defines the actual logic for each component of the system • Component Tests are created in this phase • Implementation Phase – (AKA Coding/Development Phase) All development or coding takes place in this phase • Once Implementation (Coding) is completed, the path of execution continues up the right side of the V-Model where the test plans created earlier are now put to us

23. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Advantages of v-model: • Simple and easy to use. • Testing activities like planning and test designing happen well before coding. • This saves a lot of time. • Hence higher chance of success than the waterfall model. • Proactive defect tracking – that is defects are found at an early stage • Avoids the downward flow of the defects • With Waterfall, a defect (failure) might be present in a requirement, but won’t be detected until later in the testing phase • Works well for small projects where requirements are easily understood. Disadvantages of v-model: • Very rigid and least flexible of all methodologies • Software is developed during the implementation phase, so no early prototypes of the software are produced. • If any changes happen midway through the project, then the test documents along with requirement documents have to be updated

24. 2. SOFTWARE DEVELOPMENT METHODOLOGIESINCREMENTAL METHODOLOGY

25. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • All of the requirements are split up into several builds (versions of the application) • Multiple development cycles take place • ”Multi-Waterfall” cycle • Cycles are divided up into smaller, more easily managed modules • Each module passes through the SDLC phases • Requirements Analysis  Design  Development  Testing  Production • A working version of the software is produced during the 1st module • Each subsequent release of a module adds functionality to the entire application • Process continues until the application is completed

26. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Advantages of incremental model: • Generates working software quickly and early during the software life cycle. • This model is more flexible – less costly to change scope and requirements. • It is easier to test and debug during a smaller iteration. • In this model customer can provide feedback with each new build that is released • Lowers initial delivery cost. • Easier to manage risk because risky pieces are identified and handled during each iteration. Disadvantages of incremental model : • Needs good planning and design. • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. • Total cost is higher than waterfall.

27. 2. SOFTWARE DEVELOPMENT METHODOLOGIESRAPID APPLICATION DEVELOPMENT

28. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • Rapid Application Development (RAD) • A type of Incremental Model • The components or functions are developed in parallel as if they were mini projects • Each development project is time-boxed, delivered, and then assembled into a working prototype • This can quickly give the customer something to see and use and to provide feedback on

29. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Advantages of RAD: • Reduced development time. • Increases reusability of components • Quick initial reviews occur • Encourages customer feedback • Integration from very beginning solves a lot of integration issues. Disadvantages of RAD : • Depends on strong team and individual performances for identifying business requirements. • Only a system that can be modularized can be built using RAD • Requires highly skilled developers/designers. • High dependency on modeling skills • Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

30. 2. SOFTWARE DEVELOPMENT METHODOLOGIESAGILE METHODOLOGY

31. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • A type of Incremental Methodology • Software is developed in incremental, rapid cycles • Each increment is called a Sprint • Results in small incremental releases with each release building on previous functionality • Each release is thoroughly tested to ensure software quality • Used for time-critical applications • SCRUM & Extreme Programming (XP) are 2 of the most commonly used Agile methodologies

32. 2. SOFTWARE DEVELOPMENT METHODOLOGIES Advantages of Agile: • Customer satisfaction by rapid, continuous delivery of useful software. • People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. • Working software is delivered frequently (weeks rather than months). • Face-to-face conversation is the best form of communication. • Close, daily cooperation between business people and developers. • Continuous attention to technical excellence and good design. • Regular adaptation to changing circumstances. • Even late changes in requirements are welcomed Disadvantages of Agile : • In the case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. • There is lack of emphasis on necessary designing and documentation. • The project can easily get taken off track if the customer representative is not clear on what final outcome that they want • Customer almost never knows what they want! • Only senior programmers are capable of taking the kind of decisions required during the development process. • Hence it has no place for newbie programmers, unless combined with experienced resources.

33. WHEN TO USE AGILE • When new changes are needed to be implemented. • The freedom agile gives to change is very important. • New changes can be implemented at very little cost because of the frequency of new increments that are produced. • To implement a new feature the developers need to lose only the work of a few days, or even only hours, to roll back and implement it. • Unlike the waterfall model, very limited planning is required with Agile in order to get started with the project. • Agile assumes that the end users’ needs are ever changing in a dynamic business and IT world. • Changes can be discussed and features can be newly effected or removed based on feedback. • This effectively gives the customer the finished system they want or need. • Both system developers and stakeholders alike, find they also get more freedom of time and options than if the software was developed in a more rigid sequential way. • Having options gives them the ability to leave important decisions until more or better data is available or even entire hosting programs are available • This means the project can continue to move forward without fear of reaching a sudden standstill.

34. 2. SOFTWARE DEVELOPMENT METHODOLOGIES • Agile Manifesto: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals & Interactions over processes & tools Working Software over comprehensive documentation Customer Collaboration over contract negotiation Responding to Change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” Types of Agile : • Extreme Programming (XP) • Lean & Kanban Development • Crystal Methods • Feature Driven Development • Scrum

35. 3. SCRUM Scrum Scrum is: • Lightweight • Simple to understand • Difficult to master • Scrum is a process framework that has been used to manage complex product development since the early 1990s • It’s not a process or a technique for building products • Scrum is a framework within which you can use various processes and techniques (CI, TDD, BDD) Components of Agile Scrum Development • The Scrum Team • Scrum Events (Ceremonies) • Scrum Artifacts • Scrum Rules

36. 3. SCRUM The Scrum Team • Scrum Teams are composed of 7 +/- 2 members (only 5-9 members) • No Team Leader to delegate tasks or decide how a problem will be solved • The Scrum Team, as a whole unit, decides how to address issues and solve problems • Each team member is an important part of the team and is expected to carry a product from inception to completion • Note – Scrum Team focuses on the “Product” not the “Project” • Product is the solution being built • Project generally refers to the effort to build an application or system

37. 3. SCRUM 3.4 Scrum Team Roles • The Product Owner • No “Project Manager” role • The ScrumMaster • The Development Team

38. 3. SCRUM Scrum Ceremonies • The Sprint • Sprint Planning • Daily Stand-up • The Sprint Review • The Retrospective

39. 3. SCRUM The Sprint • A Time-Boxed period • Specific work is completed & ready for review within this time-boxed period • 2-4 weeks long • Can be as short as 1 week • Inspection and adaptation occurs on a daily basis • Assess progress towards the sprint goal – When? • No changes to requirements are made during a Sprint

40. 3. SCRUM Scrum Artifacts • Product Backlog • Sprint Backlog • Increment • PSI

41. 3. SCRUM Scrum Rules • Rules of Agile Scrum should be completely up to the team and governed by what works best for their process • The best Agile Coaches will tell teams to start with the basic scrum events mentioned earlier and then inspect and adapt based on the team’s unique needs • Continuous improvement in the way the team functions together as a whole

42. 4. ALL ABOUT TESTING All about testing:

43. 4. ALL ABOUT TESTING Topics: • Testing Myths • Types of Testing • Testing Methods • Testing Levels • Testing Documentation Types of Testing • Manual Testing: • Unit Testing, Integration Testing, System Testing, User Acceptance Testing (UAT) • Automation Testing: It’s done by using a programming/scripting language (VBScript, JavaScript, etc.) and an automation testing tool (HP UFT, Selenium, etc.

44. 4. ALL ABOUT TESTING Testing methods: • Black-Box Testing • White-Box Testing • Also called Glass-Box Testing, Open-Box Testing • Grey-Box Testing Testing levels: • Functional Testing, Unit Testing, Integration Testing, System Testing, Regression Testing, Acceptance Testing, Alpha Testing, Beta Testing, Non-Functional Testing, Load Testing, Stress Testing Testing Documentation: Test Plan, Test Scenario, Test Case, Traceability Matrix

45. 4. ALL ABOUT TESTING Scenario: Testing user login Functionality: Testing:

46. 4. ALL ABOUT TESTING Integration Testing VS System Testing : • Dev 1 => Component A - Unit Test 1 Dev 2 => Component B - Unit Test 2 Dev 3 => Component C - Unit Test 3 Dev 4 => Component D - Unit Test 4 Part 1 Part 2 • Integration: (Component A + Component B) AND (Component C + Component D)Integration Testing: Is part 1 working properly? AND Is Part 2 working properly? Application & Architecture • System Integration: Part 1 + Part 2 (A+B+C+D)System Testing: Is the application and it's architecture working properly?

47. 4. ALL ABOUT TESTING IEEE 829: IEEE 829 also is referred to as the 829 Standard for Software Test Documentation. • An IEEE standard for documenting the testing of software. The standard typically applies to any stage in the testing of developing software, and each stage in the software's development typically is documented using the same application of the standard. The IEEE specifies eight stages in the documentation process, each stage producing its own separate document. • IEEE 829 – Software Test Documentation Standards • Standard doesn’t require the use of any specific document, but lays out standards for the format of various test documents

48. 5. Software Testing Life Cycle STLC: Software Testing Life Cycle • The process of testing a software in a well planned and systematic way Generic Phases of the STLC: • Requirements Analysis • Test Planning • Test Analysis • Test Design • Test Construction/Verification • Test Execution & Bug Reporting • Final Testing & Implementation Post Implementation

49. 5. SOFTWARE TESTING LIFE CYCLE Test Planning • IEEE 829 – Software Test Documentation Standards • Test Plan is a Dynamic Document Test Analysis • Determine what testing needs to be completed in each SDLC phase Test Design • Every test case must have at least the following: • Test Case ID • Test Case Name • Test Case Description • Step Name • Step Description • Expected Result • RTM Information

50. 5. SOFTWARE TESTING LIFE CYCLE Final Testing & Implementation • Final testing is conducted: • Stress, Performance, Load testing • Software is verified in an environment similar to production • Some organizations set up their QA or UAT environments to be just like production to save time