Data Flow Diagram - DFD Levels, Symbols, Case Study, Tutorial, Example,

Validating the DFD Before moving on from this initial high-level DFD, we must ensure it is consistent. Below is a checklist of points to watch out for before moving on to a detailed investigation which will take us to lower levels. 1.    Has each process a strong imperative verb and object? 2.    Are data flows in related to data flows out? Data should not be swallowed up by a process, only transformed in some way. A data store is the only place data is allowed to rest. Similarly, data cannot be generated by a process. A document may be, but the data on the document comes from a data flow into that process. 3.    Can the flows be reduced? If a process is too busy, it can perhaps be broken down into two or more processes: six data flows in or out of a process should be enough. 4.    Do all data stores have flows both in and out? A one-way data store is of little use, unless it is a reference file. If the Cur...

Developing Data Flow Diagrams The most comprehensive and useful approach to developing an accurate and complete description of the current system begins with the development of a physical data flow diagram. The use of physical data flow diagrams is desirable for three reasons: 1.    Analysts initially find it easier to describe the interaction between physical components than to understand the policies used to manage the application. Identifying people, what they do, which documents and forms trigger which activities and what equipment is used in the processing. The movement of people, documents and information between departments and locations is also identified. 2.    Physical data flow diagrams are useful for communicating with users. Users relate easily to people, locations and documents as they work with these each day. Users may consider logical DFDs abstract as they do not contain th...

Physical and Logical DFDs There are two types of data flow diagrams, namely physical data flow diagrams and logical data flow diagrams and it is important to distinguish clearly between the two: Physical Data Flow Diagrams An implementation-dependent view of the current system, showing what tasks are carried out and how they are performed. Physical characteristics can include: Names of people Form and document names or numbers Names of departments Master and transaction files Equipment and devices used Locations Names of procedures Logical Data Flow Diagrams   An implementation- in dependent view of the a system, focusing on the flow of data between processes without regard for the specific devices, storage locations or people in the system. The physical characteristics listed above for physical data flow diagrams will not be specified.

             Alpha and Beta Testing Acceptance Testing Making sure the software works correctly for intended user in his or her normal work environment. Alpha test (version of the complete software is tested by customer under the supervision of the developer at the developer’s site) Beta test (version of the complete software is tested by customer at his or her own site without the developer being present) Software can be built as a custom software, (e.g. MIS for a particular organization) for one customer or as a product to be used by many customers. When it is developed as custom software, a series of acceptance tests are conducted to enable the customer to validate all requirements. They are conducted by the end-user rather than software engineers and may be conducted over a period of weeks or months. In case of software being developed as a product it is not possible to have acceptance testing by each end-user and hence a process called alp...

Validation and Verification Software testing is one element of a broader topic that is often referred to as verification and validation. Other elements in V and V are other SQA activities like FTR, quality and configuration audit, performance monitoring, simulation, feasibility study, documentation review etc. Verification  refers to the set of activities that ensure that software correctly implements a specific function (whether it is required or not is a different issue).    Validation  refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements. Verification  – “Are we building the product right?” Validation      - “Are we building the right product?”

Black-Box Testing Strategy Black-box testing also called behavioral testing focuses on the functional requirements of the software. It is not an alternative to white-box testing. It is a complementary approach that is likely to uncover a different class of errors than white-box testing. It attempts to find errors in the following categories: i. Incorrect or missing functions ii. Interface errors iii. Errors in data structures or external database access iv. Behavior or performance errors v. Initialization and termination errors Since we are looking at procedural details / internal logic in white-box testing it is performed on components and hence during the early part of testing. Black-box testing is applied at the later stages of testing.              Graph-Based Testing Methods Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph In this ...