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

Key Points : Testing Strategies. User Training. Training Methods. Conversion Methods. Post Implementation Review. Hardware Selection. Software Selection. Team Management.

Testing Strategies: - A Test Case is a set of data that the system will process as normal input. - Each Test Case is designed with the intent of finding errors. There are two general strategies for testing software. Code Testing: (White Box Testing) - It examines the logic of the program. Every Instruction and Path is tested in this strategies. Virtually impossible to perform this kind of testing for large business system. It doesn’t guarantee against software failure,even if we perform it. We can’t check whether software meets its specification. It doesn’t check the range of data that the program will accept. Specification Testing: (Black Box Testing) We can check whether software meets its specification under various condition. Assumption is that “If program meets the specification, It will not fail. More efficient because it focus on the way software is expected to be used.

User Training It may involve equipment use. (How to operate the equipment?) Instruct individuals in troubleshooting the system. (With Help Documentation) Most user training deals with the operation of the system itself.(Data Preparation) Training for data handling activities. (Editing,Deleting,Searching,Formulating) Training for system maintenance. (Disk Change,Loading Paper) There are two aspects of User training. 1. Familiarization with the processing system. 2. Training in using the application. - Good Documentation, although essential, does not replace training. Training activities may tack place at Vendor location, at rented facilities OR In-House at the employees’ organization. Vendor and In-Service Training: - Most vendors offer extensive educational program as part of their service. - There is a charge,but in many instances Training is free. - This training is Hands-on, so participants actually use the system in presence of trainers. - Generally,

“Conversion is the process of changing from the old system to the new one” There are four methods of handling a system conversion. 1. Parallel System: - Both system runs in parallel. Advantage : - Safest conversion approach. Disadvantage : - System costs double 2. Direct Cutover: - converts from the old system to the new system abruptly. (1-2 days) Disadvantage : - No other system to fall back on. - Wise and careful planning is required. 3. Pilot Approach: - When new systems also involve new techniques or drastic changes in organization performance. - System is implemented in one part or one department of the organization. - When system is deemed complete, it is installed throughout the organization, either using Direct Cutover Method or Phase-In Method. Advantages: - Providing a sound proving ground before full implementation. 4. Phase-In Method: - Used when that is not possible to install a new system throughout an organization. - Implementation p

After system is implemented and conversion is complete, a review of the system is usually conducted by Users and Analysts. It provides the first source of information for maintenance requirements. Review Questions: The most fundamental concern is determining whether the system has met its aim. The System’s output quality merits special attention. (Report Format) Is the system easy to use? User Confidence is generally also an indicator of system quality. The questions of Accuracy,Completeness,Timeliness, and Usability. Benefits of Use and Easy of Use balance each other. Review Methods: These methods emphasize the importance of collecting both quantitative and subjective data to determine the suitability of the system. Such Techniques are (1) Event Logging (2) Impact Evaluation (3) Attitude Surveys. (1) Event Logging: - Requires user to record unusual or unexpected events that impact the system. (Print screen, Video Recording) (2) Impact Evaluation: - De

Chief-Programmer Team: - Team Members: Chief programmer, Backup Programmer, Programming Librarian (External & Internal Program Library) Specialist Team: - Team Members: Chief programmer, Backup Programmer, Programming Librarian, Administrator, Tool smith, Test Specialist, Documentation Editor, Other Specialist as needed (Involves individuals who have specific Expertise) Leaderless Team: - Team Members: Same as either other format. (No Permanent Leader, Team stays together from project to project)

Determining Size and Capacity Requirements: - Internal Memory Size. - Processing Speed. - No of I/O channel. - Characteristics of display and communication components. - System Supports and Utility S/W available. - Type of Auxiliary Storage Unit can attached. Computer Evaluation and Measurement: 1. Benchmarking : - Benchmark is the application of synthetic program to emulate the actual processing work handle by computer system. - Demonstrate data storage equipment techniques and provide the opportunity to test specific function performed by the system. - Examples: Speed of the central processor. - System Simulator is the alternative of Benchmarking. - System Simulators are used to determine performance differences. 2. Design of Synthetic Programs: - A Synthetic Job is a program written to exercise a computer’s resources in a way that allows the analyst to imitate the expected job stream and determine the result. - The Synthetic Job can be adjusted to produc

Evaluation of Software: - Application Requirements Questions: 1. What transactions and what data about each transaction must be handled? 2. What reports, documents, and other output must be system produce? 3. What files and databases drive the system? 4. What transaction files are needed to maintain them? 5. What is the volume of data to be stored? 6. What volume of transactions will be processed? 7. What inquiry requirements must be software support? 8. What are the limitations of the software? - Flexibility: - The ability to meet changing requirements and varying user needs. - Areas where flexibility wanted are – Data Storage, Reporting and option Data Input, Types of hardware it supports. - Audit and Reliability Provisions: - Auditor must have the ability to validate reports and output and to test the authenticity and accuracy of data and information. - System Reliability means that the data are reliable ,that they are accurate and believable. - Example: Passw

Those projects that are developed on time have these characteristics in common. 1. a carefully formulated estimation of time requirements. 2. a means for management to monitor progress. 3. a means for comparing actual against planned performance. 4. sufficient information to deal with problems when they arise. Estimating Time Requirements: - Estimates are approximation of the Hours, Days, or Months of effort needed to produce the desired system. - Accuracy of approximation is dependent on the Skills, Knowledge, and Experience of the Estimator (Project Manager). - In many cases determined by Factors Such as * Analyst’s and Programmer’s Abilities. * Systems Complexities. * Interruption not related to project.

There are three common methods of estimating project development times. 1.Historical Method: - It is based on careful Records of past project. - New Projects are compared with the records on file of past efforts. - Many Companies prefer to avoid. (Time Consuming) - It is only as good as records and even then it is useful only if it fits the characteristics of a prior development. 2.The Intuitive Method. - Relies on the Experience of Estimator. (Senior Personnel, Project Manager) - Most widely used approach.(Being Quick and Convenient) - Documented cases and Detailed records are not used. 3.Standard Formula Method . - Offers more concrete approach to estimation. - Individual factors are identified and quantified. - Formula specifies how to relate the individual element to produce an estimate of development time in Hours, Days, or Weeks.

Preparation of System Documentation There are Six major types of Documentation.(By Fitzgerald) 1. System Documentation: - Overall System Design. - System Flowchart. - Input / Output Formats. - File Description. - Report Specification. 2. Programming Documentation:(Use by Technical Personnel) - Programming Specification. - Description of Program Logic. 3. Operation Documentation: (Developed for Users) - Operating Instruction for normal operations. - Directions for handling Problems and Breakdowns. 4. Training Documentation: (Developed for Trainees/Users) - Training Manuals and Materials. 5. Implementation Documentation: (Developed for Customer/Management) - Implementation Plans and Result of implementation. 6. Appendix: - contains all other documentation. For Example : - Feasibility Study Report. - Problem Definition Report. - Study Plan. - Normalization Documentations. Need for Documentation: Without proper documentation, effective communicati

                   A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system

Entities: can be people, departments, other companies, other systems… are called sources if they are external to the system and provide data to the system, and sinks if they are external to the system and receive information from the system Processes must have at least one input and at least one output at the primitive level (see below) are labeled with verb + object (e.g. “print invoice” or “add customer”) (e.g. in the hierarchy below, none of the processes are primitive) at the non-primitive level, are labeled more generally (e.g. “customer maintenance” or “warehouse reports”) Data stores: · can be online or “hard copy” (see notes on logical VS physical DFD’s below) · are labeled with a noun (e.g. the label “customer” indicates that information about customers is kept in that data store) · data is stored whenever there are more than one process that needs it and these processes don’t always

A data-flow diagram ( DFD ) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing ( structured design ). On a DFD , data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process . A DFD provides no information about the timing or ordering of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD ).