System models of sdlc- v model

1,414
-1

Published on

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

No Downloads
Views
Total Views
1,414
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

System models of sdlc- v model

  1. 1. SYSTEM MODELS OF SDLC :- ‘V’ MODEL BY:- MINAL KASHYAP
  2. 2. SDLC :- SOFTWARE DEVELOPMENT LIFE CYCLE • Definition :-A software development process, also known as a software development life-cycle, is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle.
  3. 3. CONTINUE… • It is a framework defining tasks performed at each step in the software development process. SDLC is a structure followed by a development team within the software organization. It consists of a detailed plan describing how to develop, maintain and replace specific software. The life cycle defines a methodology for improving the quality of software and the overall development process. This term is also known as the software development process.
  4. 4. PHASES OF SDLC :-
  5. 5. Each Phase has an “Output” Phase  Requirements analysis  Design  Implementation  Test Output  Software Requirements Specification (SRS), Use Cases  Design Document, Design Classes  Code  Test Report, Change Requests
  6. 6. Models  Different projects may interpret these phases differently.  Each particular style is called a “Software Life-Cycle Model”
  7. 7. “Life-Cycle” Models  Single-Version Models  Incremental Models  Single-Version with Prototyping  Iterative Models
  8. 8. “Life-Cycle” Models (1)  Single-Version Models  Big-Bang Model  Waterfall Model  Waterfall Model with “back flow”  “V” model: Integrating testing
  9. 9. ‘V’ MODEL • V model means verification and validation model. • The V-model represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. • Each phase has to be completed before the next phase begins. • Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape.
  10. 10. • Testing is emphasized in this model more than in the waterfall model. • It is a structured approach to testing. • Brings high quality into the development of our products. • The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.
  11. 11. “V” Model Each phase has corresponding test or validation counterpart Requirements Analysis System Design Program Design Implementatio n Unit Test Integration Test Acceptance Test
  12. 12. Steps in the V-Shaped Model Quality is guaranteed at each project stage.
  13. 13. VERIFICATION PHASES 1.Requirements analysis • In this phase, the first step in the verification process, the requirements of the system are collected by analysing the needs of the user. • This phase is concerned with establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. • Usually, the users are interviewed and a document called the user requirements document is generated.
  14. 14. • The user requirements document will typically describe the system’s functional, interface, performance, data, security, etc. requirements as expected by the user. • It is used by business analysts to communicate their understanding of the system to the users. • The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. • There are different methods for gathering requirements of both soft and hard methodologies including; interviews, questionnaires, document analysis, observation, throw-away prototypes, use cases and static and dynamic views with users.
  15. 15. • Systems design is the phase where system engineers analyse and understand the business of the proposed system by studying the user requirements document. • They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. 2. System design
  16. 16. • The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. • It may also hold example business scenarios, sample windows, reports for the better understanding. • Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing are prepared in this phase.
  17. 17. 3.Architecture design • The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in the particular phase.
  18. 18. 4.Module design • The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code: • database tables, with all elements, including their type and size • all interface details with complete API references • all dependency issues • error message listings • complete input and outputs for a module. • The unit test design is developed in this stage.
  19. 19. Unit testing  The most ‘micro’ scale of Testing  A unit = smallest testable software component  Objects and methods  Procedures / functions  Performed by Programmer  A tester can help.  Requires detailed knowledge of the internal program design and code.  The units are tested in isolation.  Ensures the component is working according to the detailed design/build specifications of the module.  Not to be confused with debugging.  Also known as component, module, or program testing.
  20. 20. Integration Testing  Testing of more than one (tested) unit together to determine if they function correctly.  Focus on interfaces  Communication between units  It is done using the integration test design prepared during the architecture design phase.  Helps assembling incrementally a whole system, ensuring the correct ‘flow’ of data from the first through the final component.  Done by developers/designers and testers in collaboration  Also called Interface Testing or Assembly Testing.
  21. 21. System testing Testing the system as a whole - Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.  Ensures that system meets all functional and business requirements. Focus  Verifying that specifications are met  Validating that the system can be used for the intended purpose  The system test design is derived from the system design documents and is used in this phase.  It can involve a number of specialized types of tests to check performance, stress, documentation etc. Sometimes testing is automated using testing tools.  Done by Independent testing group
  22. 22. Acceptance testing  To determine whether a system satisfies its acceptance criteria and business requirements or not.  Similar to System testing in that the whole system is checked, but the important difference is the change in focus.  Done by real business users.  It enables the customer to determine whether to accept the system or not.  Also called as Beta Testing, Application Testing or End User Testing.  Approach  Should be performed in real operating environment .  Customer should be able to perform any test
  23. 23. • Faults are prevented and it stops fault multiplication. • Avoids the downward flow of defect. • Lower defect Resolution cost due to earlier detection. • Improved quality and reliability. • Reduction in the amount of Re-work. • Improved Risk Management • Validation and Verification at each level of stage containment • Allows testers to be active in the project early in the project’s lifecycle. They develop critical knowledge about the system. Benefits of V-Model

×