Idea Transcript
Hirendradeora's Blog November 20, 2014
CASE ( COMPUTER AIDED SOFTWARE ENGINEERING ) LAB OR SOFTWARE ENGINEERING LAB Leave a comment SOME IMPORTANT FILES TO DOWNLOAD HERE LAB MANUAL CASE Lab Manual (https://hirendradeora.files.wordpress.com/2014/11/case-lab-manual.doc) TEMPLATES VCET_SDD_Template (https://hirendradeora.files.wordpress.com/2014/11/vcet_sdd_template.doc) VCET_SRS_Template (https://hirendradeora.files.wordpress.com/2014/11/vcet_srs_template.doc) VCET_TPD_Template (https://hirendradeora.files.wordpress.com/2014/11/vcet_tpd_template.doc) CASE LAB MANUAL A Software Requirements Specification (SRS) – a is a complete description of the behavior of a system to be developed. It includes the description of all the interactions the users will have with the software. It also describes the functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). A basic purpose of software requirements specification is to bridge the communication gap between the user & system analyst, SRS is the medium through which the client and user needs are accurately specified; indeed SRS forms the basis of software development. A good SRS should satisfy all the parties- sometimes very hard to achieve and involves trade off and persuasion. Another important purpose of developing an SRS is helping the clients to understand their own needs. SRS sets the stage for the project development. It incorporates detailed study of the existing system as well as the developing system. The detailed study of the scope of the system, product perspective, function, intended users, design constraints, performance requirement and many more concepts related to the developing projects. A Software Design Document (SDD) is a written description of a software product, that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, a design document is required to coordinate a large team under a single vision. A design document needs to be a stable reference, outlining all parts of the software and how they will work. The document is commanded to give a fairly complete description, while maintaining a high-level view of the software. The SDD contains the following documents: 1. The Data Design describes structures that reside within the software. Attributes and relationships between data objects dictate the choice of data structures. 2. The Architecture Design uses information flowing characteristics, and maps them into the program structure. The transformation mapping method is applied to exhibit distinct boundaries between incoming and outgoing data. The Data Flow diagrams allocate control input, processing and output along three separate modules. 3. The Interface Design describes internal and external program interfaces, as well as the design of human interface. Internal and external interface designs are based on the information obtained from the analysis model. 4. The Procedural Design describes structured programming concepts using graphical, tabular and textual notations. These design mediums enable the designer to represent procedural details, that facilitates translation to code. This blueprint for implementation forms the basis for all subsequent software engineering work. A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers. Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include one or more of the following: Design Verification or Compliance test – to be performed during the development or approval stages of the product, typically on a small sample of units. Manufacturing or Production test – to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. Acceptance or Commissioning test – to be performed at the time of delivery or installation of the product. Service and Repair test – to be performed as required over the service life of the product. Regression test – to be performed on an existing operational product, to verify that existing functionality didn’t get broken when other aspects of the environment are changed (e.g., upgrading the platform on which an existing application runs). A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components. A Test Plan Document (TPD) is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be. Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: Test Coverage, Test Methods, and Test Responsibilities. These are also used in a formal test strategy. Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access. Test methods in the test plan state how test coverage will be implemented. Test methods may be determined by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods also specify test equipment to be used in the performance of the tests and establish pass/fail criteria. Test methods used to verify hardware design requirements can range from very simple steps, such as visual inspection, to elaborate test procedures that are documented separately. Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also includes, what data will be collected, and how that data will be stored and reported (often referred to as “deliverables”). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties. A test case is usually a single step, or occasionally a sequence of steps, to test the correct behaviour/functionalities, features of an application. An expected result or expected outcome is usually given. Additional information that may be included: test case ID test case description test step or order of execution number related requirement(s) depth test category author check boxes for whether the test is automatable and has been automated. Additional fields that may be included and completed when the tests are executed: pass/fail remarks
Report this ad
Report this ad Posted by hirendradeora.
Create a free website or blog at WordPress.com.