4 sdlc and stlc

11,824 views

Published on

Software Development Life Cycle and Testing Life Cycle

Published in: Education, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,824
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
150
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

4 sdlc and stlc

  1. 1. System Analysis and Design The Systems Analysis and Design (SAD) is the process of developing Information Systems (IS – Acquiring and installing system environment; creating and testing databases, creating test case procedures, creating test data, coding, code refining, perform test readiness review and procurement activities ) that effectively use hardware, software, data, processes, and people to support the company’s business objectives. System A set of detailed methods, procedures, and routines established or formulated to carry out a specific activity , perform a duty, or solve a problem. Analysis The process of identifying problems, resources, opportunities, requirements and constraints Design The business of finding a way to meet the functional requirements within the specified constraints using the available technology. 1 Anyone who has never made a mistake has never tried anything new.
  2. 2. What is Software Development Life Cycle (SDLC)? Software Development Life Cycle (sometimes referred to as the System Development Life Cycle) is a process of creating or altering information systems, and the models and methodologies that people use to develop. It adheres to different phases or stages of a project from inception through completion and delivery of the final product and maintenance too. Computer systems are complex and often (especially with the recent rise of service-oriented architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models or methodologies have been created, Waterfall, Spiral, Incremental, Agile etc. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. 2 Anyone who has never made a mistake has never tried anything new.
  3. 3. Software Development Life Cycle It has 3 identifiable phases. SDLC phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project. 1. 2. 3. Definition Development Maintenance Definition phase focuses on WHAT      What information is to be processed? What functions and performances are desired? What interfaces are to be established? What design constraints exists? What validation criteria is required to define a success system? 3 Anyone who has never made a mistake has never tried anything new.
  4. 4. Software Development Life Cycle Development phase focuses on HOW     How the database should be designed? How the software architecture to be defined? How the design will be translated into code? How testing will be performed? There are 3 specific steps in development phase are 1. Design 2. Coding 3. Testing (ignored due to lack of time, due time to market, additional cost involved, lack of testing requirement understanding etc.) 4 Anyone who has never made a mistake has never tried anything new.
  5. 5. Software Development Life Cycle Maintainability is defined as the ease with which software can be understood, corrected, adapted and enhanced. Maintenance Phase focuses on CHANGE     Error correction. Adoption required as the software environment evolves. Enhancements brought about by changing customer requirements. Reengineering carried out for performance improvements. 5 Anyone who has never made a mistake has never tried anything new.
  6. 6. Software Development Life Cycle 6 Anyone who has never made a mistake has never tried anything new.
  7. 7. Software Development Life Cycle - Phases Phase 1. Initiation (Identifies a need or an opportunity) Phase 2. System concept development (Prepares systems boundary document, perform cost benefit analysis, Risk management plan and feasibility study) Phase 3. Planning (Develop project management plan and other planning docs) Phase 4. Requirement Analysis (Analyses user needs and develops user requirements. Create detailed functional requirements document (FRD)) Phase 5. Design (Transforms user requirements into complete/detailed system design. It focuses on HOW) Phase 6. Development (Converts design into a complete information system) Phase 7. Integration and Test (Demonstrate that developed system conforms to requirements in FRD. Produce test analysis reports) Phase 8. Implementation (Implementation preparation, Implementation of the system into production environment, and resolution of problems identified in the integration and test phases) Phase 9. Operation and Maintenance (Describe tasks to operate and the system developed) Phase 10. Disposition (Describe end to end activities) 7 Anyone who has never made a mistake has never tried anything new.
  8. 8. SDLC Phases          Initiation: Request for proposal Proposal Negotiation Letter of Intent Contract User Requirement Specification Software Requirement specification  Software Requirement Specification is a means of translating the ideas in the minds of the clients(the inputs) into a set of formal document (the output) of the requirement phase. The role of it use to bridge the communication gap between the client and the developer. Preliminary analysis: The objective of this phase is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations. 8 Anyone who has never made a mistake has never tried anything new.
  9. 9. SDLC Phases  Conduct the preliminary analysis: In this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Then you need to see how the problem being studied fits in with them.  Propose alternative solutions: Alternate proposals may come from interviewing employees, clients , suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system.  Describe the costs and benefits  Systems analysis and requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs. This step involves breaking down the system in different pieces to analyze the situation, analyzing project goals, breaking down what needs to be created and attempting to engage users so that definite requirements can be defined. In the requirement phase we gather as much information as possible about the detail and specifications of the desired soft ware from the client. 9 Anyone who has never made a mistake has never tried anything new.
  10. 10. SDLC Phases  Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems. The design stage takes as its initial input the requirements identified in the approved requirements document HLD and LLD phases put together called Design phase .  High Level Design (Macro Level): High level design documents contain the items listed below 1. List of modules and a brief description of each 2. Brief functionality of each module 3. Interface relationship among modules 4. Dependencies between modules 5. Database tables identified with key elements 6. Overall architecture diagrams along with technology details 7. Business team provide sign-off for this design only 10 Anyone who has never made a mistake has never tried anything new.
  11. 11. SDLC Phases  Low Level Design (Micro Level): Low level design documents contain the items listed below. 1. Detailed functional logic of the module, in pseudo code 2. Database tables, with all elements, including their type and size 3. All interface details 4. All dependency issues 5. Error message listing 6. Complete input and output format of a module 7. Business team will not provide sign-off for this design.  Development: The real code is written here.  Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Test Environment is an environment utilized to simulate normal business transactions, processes, and activities during functional testing of software.  Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.  Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This is often the longest of the stages. 11 Anyone who has never made a mistake has never tried anything new.
  12. 12. V Model  If you are working in large project, where the systems are complex, its easy to miss out key details in the requirements phase itself. In such cases , an entirely wrong product will be delivered to the client. You will have to start a fresh with the project.  Or if you manage to note the requirements correctly but make serious mistakes in design and architecture of you software you will have to redesign the entire software to correct the error.  Assessments of thousands of projects have shown that defects introduced during requirements & design make up close to half of the total number of defects.  Also, the costs of fixing a defect increases across the development life cycle. The earlier in life cycle a defect is detected, the cheaper it is to fix it.  To address this concern , the V model of testing was developed where for every phase , in the Development life cycle there is a corresponding Testing phase.  In the V model diagram provided below, the left side of the model is Software Development Life Cycle (SDLC) and the right side of the model is Software Test Life Cycle (STLC). The entire figure looks like a V, hence the name V - model 12 Anyone who has never made a mistake has never tried anything new.
  13. 13. V Model  The V model is an industry standard framework that shows clearly the software development life cycle in relation to testing. It also highlights the fact that the testing is just as important as the software development itself.  In V-Model testing begins as early as possible in the project life cycle. There are a variety of testing activities that need to be performed before end of the coding phase. These activities should be performed in parallel to the development activities so that testers can produce a set of test deliverables.  The V-Model illustrates that testing activities (verification and validation) can be integrated into each phase of the project life cycle.  Verification (are we building the product right?): The process of determining whether or not the projects of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing and inspection. All Quality Control activities through out the life cycle that ensures that all deliverables from different phases meet their specification.  Validation (are we building the right product?): The process of evaluation software at the end of the software development process to ensure compliance with software requirements. It is a process of controlling that data inserted into an application satisfies pre-determined formats or complies with stated length and character requirements and other defined input criteria. The techniques for validation are testing and inspection. The testing phase of the life cycle ensures that the end product meet the user needs  Normally, testing of any Large Systems will be in TWO parts. The functional verification and validation against the Requirement Spec and Performance evaluation against the indicated requirements.  Testing activity is involved right from the beginning of the project. Anyone who has never made a mistake has never tried anything new. 13
  14. 14. V-Model (SDLC & STLC) 14 Anyone who has never made a mistake has never tried anything new.
  15. 15. Testing Through Life Cycle 1. 2. 3. 4. 5. 6. Requirement AnalysisTesting Design Testing Unit Testing Integration Testing System Testing User Acceptance Testing 15 Anyone who has never made a mistake has never tried anything new.
  16. 16. 1. Requirement AnalysisTesting The objective of Requirement Analysis Testing is to ensure software quality by eradicating errors as early as possible in the development process, as the errors noticed at the end of the software life cycle are more costly compared to that of early ones, and there by validating each of the Outputs. The objective can be achieved by three basic issues: 1. Correctness 2. Completeness 3. Consistency 16 Anyone who has never made a mistake has never tried anything new.
  17. 17. Types of Requirements In short, software requirements are typically broken down into two major categories:  Functional requirements  Non-functional requirements Functional requirements describe the behavior and capabilities of a software system, and the information the system will manage. Functional requirements are typically described in a series of "the system will" or "the system shall" statements. Non-functional requirements are all the other requirements that don't describe the behavior of the system. Example #1: Look and Feel requirement might state that "The system shall use the corporate colors and logo“ Example #2: A Performance requirement might state that "The system shall handle a simulated user load of 1,000 users" Non-functional software requirements are then broken down into several sub-categories, like this:  Reliability  Data  Performance  Look and Feel  Operational (or Operability)  Security  Compatibility  Maintainability  Transferability 17 Anyone who has never made a mistake has never tried anything new.
  18. 18. What constitutes “good” requirements? 1. Verifiable: The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. Bad Example Requirement #1: The system must be user friendly. How to measure user friendliness? Good Example Requirement #1: The UI should be menu driven and provide dialog boxes, help screens, radio buttons, dropdown boxes etc. 2. Clear & Concise: The requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things: I) Identify the problems that need to be solved. II) Explain why those problems are worth solving. III) Define when those problems are solved Bad Example Good Example Requirement #1: Navigation from one screen to another Requirement #1: Navigation from one screen to should be very quickly. another should be <= 2 seconds How long is very quickly? 3. Unambiguous : The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Unnecessary narrative or non-relevant facts, vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided. 18 Anyone who has never made a mistake has never tried anything new.
  19. 19. What constitutes “good” requirements? 4. Complete: The requirement is fully stated in one place with no missing information. Bad Example Good Example Requirement #1: If the system failure occurs in Prod, Requirement #1: If the system failure occurs in an error notification should be sent. Prod, an email error notification should be sent to To whom and what format? Prod_Support@XX.com (Email notification format/screen should be provided) 5. Consistent: The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. Consistent Requirements are requirements that  Are not in conflict with any of your strategic objectives, vision, or corporate goals.  Avoid logical inconsistencies  Utilize consistent structure, terms, and grammar 6. Traceable: The requirement meets all or part of a business need as stated by stakeholders and authoritatively Bad Example Good Example documented. Requirement #1: The system must generate batch end Requirement #1: The system must generate a batch report and discrepancy report when a batch is aborted. How is this uniquely identified? If the requirement is changed later so that it does not require a discrepancy report, how will you trace it back to so you can delete it? end report when a batch is aborted. Requirement #2: The system must generate a discrepancy report when a batch is aborted or completed. 19 Anyone who has never made a mistake has never tried anything new.
  20. 20. What constitutes “good” requirements? Feasible: Feasibility means that a requirement can be accomplished within the cost and schedule, can be met using existing technology. Bad Example Good Example Requirement #1: The replacement control system shall be installed Requirement #1: The replacement control system shall be with no disruption to production. installed causing no more than 2 days of production disruption. This is an unrealistic expectation. etc. 20 Anyone who has never made a mistake has never tried anything new.
  21. 21. Changes in Requirements Requirements generally change with time. Once defined and approved, requirements should fall under change control process. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. What is Change control? Change control is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change. 21 Anyone who has never made a mistake has never tried anything new.
  22. 22. Requirements Analysis  Difficulties in conducting requirements analysis:     Analyst not prepared Customer has no time/interest Incorrect customer personnel involved Insufficient time allotted in project schedule  Testing related activities during Requirement phase     Creation and finalization of testing templates Creation of Test Strategy (Master Test Plan) Capturing Acceptance criteria and preparation of Acceptance Test Plan Capturing Performance criteria of the software requirements 22 Anyone who has never made a mistake has never tried anything new.
  23. 23. 2. Design Testing The objective of the design phase testing is to generate a complete specifications for implementing a system using a set of tools and languages.       Design objective is fulfilled by five issues Consistency Completeness Correctness Feasibility Tractability 23 Anyone who has never made a mistake has never tried anything new.
  24. 24. 2. Design Testing     Testing activities in System Testing phase System test is done for validating the product with respect to client requirements Testing can be in multiple rounds Defect found during system test should be logged into Defect Tracking System for the purpose of tracking.  Test logs and defects are captured and maintained.  Review of all the test documents 24 Anyone who has never made a mistake has never tried anything new.
  25. 25. 3. Unit Testing It is the most ‘micro’ scale of testing and focus on to test particular functions or code modules. This testing performed by programmers not by testers, as it requires detailed knowledge of the internal program design and code. The main objective of unit testing is to ensure that the individual units of a system work correctly in isolation, before they are eventually integrated  Unit testing objective is fulfilled by four issues     Completeness Correctness Early Testing Debugging 25 Anyone who has never made a mistake has never tried anything new.
  26. 26. 4. Integration Testing Integration testing of combined parts of an application to determine if they function together correctly. Here parts of the application can be code modules, individual applications, client and server applications on a network The main objective of integration testing is minimizing the errors which include internal and external Interface errors.  Testing activities in Integration Testing Phase  This testing is conducted in parallel with integration of various applications (or components)  Testing the product with its external and internal interfaces without using drivers and stubs.  Incremental approach while integrating the interfaces. 26 Anyone who has never made a mistake has never tried anything new.
  27. 27. 5. System Testing  Software once validated for meeting functional requirements must be verified for proper interface with other system elements like hardware, databases and people.  System testing verifies that all these system elements mesh properly and the software achieves overall function/performance.  We carry out functionality testing, performance testing and other black box testing to requirement as part of system testing.  Testing activities in System Testing phase.  System test is done for validating the product with respect to client requirements.  Testing can be in multiple rounds.  Defect found during system test should be logged into Defect Tracking System for the purpose of tracking.  Test logs and defects are captured and maintained.  Review of all the test documents. 27 Anyone who has never made a mistake has never tried anything new.
  28. 28. Testing Life Cycle – V&V Process Model Definition: V&V – a system engineering discipline employing a rigorous methodology for evaluating and assessing the correctness and quality of software throughout the software life cycle. Verify a developers process is technically sound. V&V usually focuses on ensuring the requirements are being met, the overall project is focused on the correct objectives, and risk is being managed.  Benefits of V&V     Early detection leads to a better solution rather than quick fixes. Validating the solution is solving the “right problem” against software requirements. Objective evidence of software and system compliance to quality standards. Support process improvements with an objective feedback on the quality of development process and products. Finally, You must note that there are numerous development life cycle models. Development model selected for a project, depends on the aims and goals of that project 28 Anyone who has never made a mistake has never tried anything new.
  29. 29. Testing Life Cycle – V&V Process Model Business requirements and Solution Architecture Acceptance Tests Master Test Strategy Project Planning HLD/LLD for each application involved Interface design Test Planning Strategy for individual applications, Test case design Solution Mapping/ Development/ Customization Release Integrated Solution Application Integration Performance Testing Incremental Integration Testing System Testing (Application level Testing) 29 Anyone who has never made a mistake has never tried anything new.
  30. 30. QA and the SDLC (In terms of Test Management tool – Quality Center (QC)) 30 Anyone who has never made a mistake has never tried anything new.
  31. 31. Testing Process and the SDLC (In terms of Test Management tool – Quality Center (QC)) 31 Anyone who has never made a mistake has never tried anything new.
  32. 32. QA Deliverables 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Master Test Plan Effort estimation document Test Team Capacity Planning, Utilization, and assignment allocations document Test Team Training Check List (Tool Training, Application Training etc.) document Test Metrics Traceability Matrix (If QA team responsible for it.) Integration Test Plan (If QA team performs this testing.) Functional Test Plan Performance Test Plan Test plan tracking sheet. Test scenarios, test cases/scripts Regression test bed Test Data creation/Usage/Maintenance strategy document Test Environment Setup details Test Execution/Completion Status reports Defect Reports Automation feasibility study report (if applicable) Functional automation model, framework and approach document Performance automation model, framework and approach document Test Closure Report QA Sign-off Etc. 32 Anyone who has never made a mistake has never tried anything new.
  33. 33. SDLC Deliverables 33 Anyone who has never made a mistake has never tried anything new.

×